· ii UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO...

i

UNIVERSIDADE ESTADUAL DE CAMPINAS

FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO

LEANDRO BARBOSA LIMA

VERIFICAÇÃO FUNCIONAL: UM AMBIENTE DE TESTE COMPUTACIONAL

PARA UM SISTEMA DIGITAL COM ABORDAGEM NA SEGURANÇA DE

HARDWARE

CAMPINAS

2018

ii

UNIVERSIDADE ESTADUAL DE CAMPINAS

FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO

LEANDRO BARBOSA LIMA

VERIFICAÇÃO FUNCIONAL: UM AMBIENTE DE TESTE COMPUTACIONAL

PARA UM SISTEMA DIGITAL COM ABORDAGEM NA SEGURANÇA DE

HARDWARE

CAMPINAS

2018

Dissertação de Mestrado apresentada

ao Programa de Pós-Graduação em

Engenharia Elétrica da Faculdade de

Engenharia Elétrica e de Computação

da Universidade Estadual de

Campinas para obtenção do título de

Mestre em Engenharia Elétrica, na

área de Telecomunicações e

Telemática.

ESTE EXEMPLAR CORRESPONDE À

VERSÃO FINAL DA DISSERTAÇÃO

DEFENDIDA PELO ALUNO LEAN-

DRO BARBOSA LIMA E ORIENTADO

PELO PROF. DR. YUZO IANO

Orientador: Prof. Dr. Yuzo Iano

iv

COMISSÃO JULGADORA – TESE DE MESTRADO

Candidato: Leandro Barbosa Lima

Data da Defesa: 29 de novembro de 2018

Título da Tese: “Verificação funcional: um ambiente de teste computacional para um sistema

digital com abordagem na segurança de hardware”

Prof. Dr. Yuzo Iano (Presidente FEEC/UNICAMP)

Prof. Dr. Sílvio Renato Messias de Carvalho (FEEC/UNICAMP)

Prof. Dr. Rogério Seiji Higa (Instituto Eldorado)

A ata de defesa, com as respectivas assinaturas dos membros da Comissão Julgadora, encon-

tra-se no processo de vida acadêmica do aluno.

v

Dedicado aos que sonham com a independência e a libertação da ciência e tecnologia do

Brasil.

vi

AGRADECIMENTOS

A Deus, por inúmeras razões.

À minha família, em especial à minha ESPOSA, meus PAIS e IRMÃOS, que a-

poiaram intensamente.

À UNICAMP, pela oportunidade de conquistar o direito de estudar nessa casa de

excelência no ensino de Engenharia.

Ao professor Yuzo Iano, ao qual tenho enorme gratidão pela confiança e paciência

em todas as etapas deste trabalho.

Aos amigos do CT2/CI-Brasil, Victor Gabriel, Ana Carolina, Wander Martins,

Lucas Andrade, Elcio Ishii e Alexsander Deucher, pela pronta ajuda sempre que necessária.

Aos amigos de Freescale, Cezar Santos, Alexandre Lujan, Walter Ensinas e Celso

Brites, também pela pronta ajuda sempre que necessária.

Aos amigos de LSITEC, Jose Ramires, Vinicius Martins, Diego Deotti, Dionísio

Carvalho, pela convivência sempre pacífica e agradável.

Aos amigos do LCV, Abel, Hermes, Júlio Leon, Agord Pinto Junior, pelo apoio

com materiais, ferramentas de teste e pelo compartilhamento de outros materiais fundamen-

tais para a realização desse trabalho.

Ao Exército Brasileiro, pela oportunidade e apoio na montagem de um laboratório

de sistemas de segurança na Subseção de Segurança da Informação com o uso de ferramentas

para testes de circuitos digitais em FPGA com abordagem na segurança de hardware.

A todos vocês, agradecemos o apoio fornecido para concluir este trabalho.

vii

“Nenhum tesouro,

por mais valioso que seja,

não supera o tesouro da honestidade”

(Meishu-Sama)

viii

RESUMO

Circuitos integrados digitais ou de sinais analógicos e digitais, CIs, desempenham um

papel importante e crítico no design e desenvolvimento dos sistemas embarcados dentro de

armas inteligentes e sistemas militares. A tremenda demanda por armas inteligentes junto com

o surgimento do terrorismo cibernético, bem como a guerra eletrônica e de informação, muda-

ram os requisitos de projeto de sensores e sistemas eletrônicos militares. O surgimento deste

cenário trouxe a necessidade de verificação do funcionamento de sistemas digitais e analógi-

cos. Deste modo, metodologias de verificação funcional começaram a se destacar no ambiente

da arquitetura digital. Com isso, a verificação funcional torna-se uma ferramenta indispensá-

vel para a construção e implementação de hardware de propósito específico, e também de

propósito geral, denominados IP Core; Semicondutor Intelectual Property Core. O trabalho de

implementação do controlador digital apresentado utiliza a linguagem de descrição de hard-

ware Verilog e para a verificação e validação dos dados, utiliza-se a e language, como desen-

volvimento de um ambiente de validação, com a finalidade de verificar o comportamento do

circuito. A integração da estrutura do sistema do conversor permite que o sistema de controle

possa ser simulado, testado e validado sem necessidade de um protótipo. A metodologia eRM

do controle digital é baseada na e language, da Versite, utilizando a ferramenta specman para

criação do ambiente de validação funcional. O código em Verilog do controle digital é utili-

zado para implementação em FPGA, do Xilinx Spartan 3E-500, que contém 500K portas de

sistema e 10.476 células lógicas equivalentes, suficiente para o propósito deste trabalho. Os

resultados processados na metodologia eRM irão mostrar os resultados alcançados com o uso

da metodologia, oferecendo maior produtividade com o reuso do código e também com a

construção do ambiente de validação, a fim de oferecer excelentes possibilidades em testes e

validação de circuitos digitais. O projeto de reutilização e reaproveitamento de código em

verificação é importante para satisfazer as exigências de tempo. O projetista deve ser capaz de

reutilizar a propriedade intelectual no projeto como modelo de referência. A reutilização do

ambiente de verificação em diferentes projetos economiza tempo e melhora a qualidade do

projeto de verificação. Um dos dispositivos de controle de processamento de sinais utiliza

como solução de estabilidade de tensão um PID, Proportional–Integral–Derivative, que faz a

parte complexa de ajustes de sinais do sistema. Este controle é chamado de conversor estático

do tipo Buck, comumente conhecido como fonte chaveada, sendo utilizado em diversas apli-

ix

cações industriais e militares, podendo também se encontrar em nosso cotidiano, destacando-

se seu uso em dispositivos móveis e espaciais.

Palavras-chave: Hardware, Circuitos Integrados Digitais, Linguagem de Programação, Siste-

mas Embarcados, Simulação, Sistemas de Segurança.

x

ABSTRACT

Integrated digital circuits as well mixed-signal circuits, CIs, have an important, and

critical, role during the design and development of embedded systems used in smart weapons

and military systems. The always-rising demand for smart weapons, due to cyber terrorism

issues, electronic warfare, and information warfare, has changed the requirements applied on

sensors projects and military systems. This scenario brought the need to verify, intensively,

analog and digital systems functionalities. In order for that, functional verification methodol-

ogies began to be a mayor question on digital architecture environment and becomes a must-

have for hardware construction and implementation, both on specific purpose as well for

general purpose hardware, been called by IP Core (Semiconductor Intellectual Property

Core). The digital controller implemented in this work uses Verilog hardware description

language, and e-language for data validation and verification, building a validation environ-

ment used for verify the circuit behavior. The converter system structure integration allows

the control system to be simulated, tested and validated without the need of a physical proto-

type. The eRM methodology of digital control is based on e language, from Versite, using the

Specman tool to create the functional validation environment. The digital controller code,

writing in Verilog, due to language portability, is used for FPGA implementation, on Xilinx

Spartan 3E-500, which contains 500K system ports and 10,476 equivalent logical cells, suffi-

cient for the purpose of this work. The goals achieved by using eRM methodology shown for

themselves that code reuse offered by this methodology guides to greater productivity, as well

make easier the construction of the validation environment, been able to produce excellent

options for tests and validation of digital circuits. During the code verification process, it is

important to avoid the code's rewriting, in order to achieve project time deadlines. The de-

signer must be able to reuse intellectual property in the project as a reference model. Re-

using the verification environment on different projects saves time and improves its quality.

One of the signal processing device control uses a PID (Proportional Integral Derivative) as

a voltage stability solution, being responsible to control the system’s complex part of signal

adjustments. This stability solution is commonly called as Buck-type static converter or also

as switched source, and it is used in many industrial and military applications, being found in

many of our daily lives devices, as mobile devices, and in space devices.

Keywords: Hardware, Digital Integrated Circuits, Programming Language, Embed-

ded Systems, Simulation, Security Systems.

xi

LISTA DE FIGURAS

Figura 1 Amostra de um Pacote do Chip.................... ................................................ 26

Figura 2 Estágios do Conversor Tipo Buck ................................................................ 36

Figura 3 Conversor CC-CC e Forma de Onda da Tensão de Saída ............................ 36

Figura 4 Ganho Estático em Função de D ................................................................. 37

Figura 5 Exemplo de um Circuito PWM .................................................................... 38

Figura 6 Conversor Buck ............................................................................................ 38

Figura 7 Forma de Onda da Tensão ............................................................................ 39

Figura 8 Ganho Estático em Função de D .................................................................. 39

Figura 9 Principais Formas de Onda do Conversor Buck ........................................... 39

Figura 10 Conversor Boost ........................................................................................... 40

Figura 11 Tensão sobre o Indutor ................................................................................. 41


Figura 13 Principais Formas de Onda do Conversor Boost .......................................... 41

Figura 14 Conversor Buck-Boost .................................................................................. 42

Figura 15 Tensão do Indutor ......................................................................................... 42


Figura 17 Principais Formas de Onda do Conversor Buck-Boost ................................ 43

Figura 18 Conversor Flyback ....................................................................................... 44

Figura 19 Tensão no Primário ....................................................................................... 44


Figura 21 Principais Formas de Onda do Conversor Flyback ...................................... 46

Figura 22 Conversor Forward ...................................................................................... 47

Figura 23 Tensão do Indutor ......................................................................................... 47


Figura 25 Principais Formas de Onda do Conversor Forward ..................................... 49

Figura 26 Exemplo de Conversor de Malha Fechada ................................................... 49

Figura 27 Contagem de Transistores ............................................................................ 54

Figura 28 Fluxograma Solucionador de Sementes ....................................................... 59

Figura 29 Fluxograma Adição de Sementes ................................................................. 60

Figura 30 Abordagem Iterativa ..................................................................................... 60

Figura 31 Manipulação de Restrições........................................................................... 61

Figura 32 Solução de Esquemas Coloridos .................................................................. 62

Figura 33 Solução de Nós Coloridos ............................................................................ 62

xii

Figura 34 Números de Série ......................................................................................... 65

Figura 35 Níveis de Abstração para Domínios de Desenvolvimento ........................... 67

Figura 36 Metodologia de Desenvolvimento ............................................................... 68

Figura 37 Fluxo de Projeto ASIC ................................................................................ 77

Figura 38 Validação de Caixa Preta .............................................................................. 78

Figura 39 Validação de Caixa Cinza ............................................................................. 79

Figura 40 Validação de Caixa Branca ........................................................................... 79

Figura 41 Validação por Simulação .............................................................................. 81

Figura 42 Representação de Casos Válidos .................................................................. 82

Figura 43 Validação Hierárquica .................................................................................. 82

Figura 44 Objetivo da Validação Específica ................................................................. 83

Figura 45 Bloco de Controle do Conversor Estático de Potência ................................ 89

Figura 46 Conversor ADC ........................................................................................... 90

Figura 47 Escala de Tempo ........................................................................................... 91

Figura 48 Módulo Top Bloco ........................................................................................ 92

Figura 49 Fios e Interconexões .................................................................................... 93

Figura 50 Entradas e Saídas .......................................................................................... 94

Figura 51 Instâncias do Módulo UART........................................................................ 94

Figura 52 Módulo DRA ................................................................................................ 95

Figura 53 Módulo PWM ............................................................................................... 96

Figura 54 Módulo PID .................................................................................................. 96

Figura 55 Módulo Soft Starter ...................................................................................... 97

Figura 56 Module Enable Sum .................................................................................... 97

Figura 57 Module Edge Detect ..................................................................................... 98

Figura 58 Module Stabilizer ......................................................................................... 98

Figura 59 Integração dos Circuitos ............................................................................. 100

Figura 60 Sistema de Validação (Ambiente de Verificação) ...................................... 103

Figura 61 Testes Direcionados .................................................................................... 105

Figura 62 Tarefa Dirigida ........................................................................................... 106

Figura 63 Verificação de IP ....................................................................................... 108

Figura 64 Simulação e Resultados da Interface Serial .............................................. 109

Figura 65 Simulação e Resultados do Acesso Direto aos Registros ........................... 111

Figura 66 Simulação e Resultados do PID ................................................................. 111

Figura 67 Simulação e Resultados do Soft Starter ..................................................... 113


xiii





Figura 73 Simulação e Resultados para Estabilizador ................................................ 116




Figura 77 Simulação e Resultados do Somador ......................................................... 118

Figura 78 Simulação e Resultados do Edge Detector ................................................ 119



Figura 81 Simulação e Resultados para PID .............................................................. 120

Figura 82 Simulação e Resultados do PWM .............................................................. 122

xiv

LISTA DE TABELAS

Tabela 1 Entradas e Saídas .......................................................................................... 91

Tabela 2 Endereços e Opcodes ................................................................................. 112

xv

LISTA DE ABREVIATURAS E SIGLAS

ASIC Application Specific Integrated Circuits

CSP Conversor Estático de Potência

FPGA Matriz de Porta Programável no Campo

DSP Digital Signal Processing - Processamento Digital de Sinais

DRA Acesso Direto aos Registros

CC/CC Buck Converter Step-down Converter - Conversor Abaixador

C++ C++ Language - Linguagem de Programação C++

e e Language - Linguagem de Programação e

eRM e Reuse Metodology

IP Propriedade Intelectual

IP Core Semicondutor de Propriedade Intelectual

LCD Liquid Crystal Display

LUTs Lookup Table

PID Proportional–Integral–Derivative Controller - Controlador Proporcional–

Integral–Derivativo

PWM Pulse Width Modulation - Modulador por Largura de Pulso

RT Register Transfer - Transferência de Registro

RTL Register Transfer Language - Linguagem de Transferência de Registro

SS Soft Starter

SOC System on Chip

UART Receptor e Transmissor Assíncrono Universal

Verilog Hardware Description Language

VCS Verify Constraint Solver

VIP Verication Intectual Property - Verificação de Propriedade Intelectual

VHSIC Very High Speed Integrated Circuits

VLSI Very Large Scale Integrated - Integração de Milhares de Transistores

CI Circuito Integrado

xvi

PUBLICAÇÕES DO AUTOR

Leandro Lima, Yuzo Iano, Architecture of a FPGA-Based Control of a Static Power Buck

Converter, Anais do V Simpósio de Processamento de Sinais da UNICAMP (SPS' 14),

Campinas, São Paulo, 2014.

ISSN 2359-3334.

DEUCHER, A. ; ISHII, H. A. ; ANDRADE, L. ; LIMA, L. ; RAMIREZ, J. ; FINCO, S. ;

FRUETT, F. Configurable Static Power Converter, IC-Brazil program success,

CADENCE USER CONFERENCE LIVE - CDNLive EMEA, Munich, 2014.

http://www.sps.fee.unicamp.br/anais/vol01/VSPS_a18_LLima.pdf

xvii

Sumário

1 Introdução ................................................................................................................................. 21

1.1 Considerações Iniciais ......................................................................................................... 21

1.1.1 Estrutura da Dissertação ........................................................................................... 22

1.1.2 Objetivos e Contribuições ......................................................................................... 24

2 Circuitos Integrados ................................................................................................................. 26


2.2 Tipos de ASIC ..................................................................................................................... 29

2.2.1 ASIC totalmente Customizados ................................................................................ 30

2.2.2 ASIC Baseados em Célula Padrão ............................................................................ 30

2.2.3 ASIC Baseados em Matriz de Portas ........................................................................ 31

2.3 Matriz de Portas Estruturadas .............................................................................................. 32

2.4 Dispositivos Lógicos Programáveis .................................................................................... 33

2.5 Matrizes de Portas Programáveis em Campo ...................................................................... 33

3 Sistemas de Eletrônica de Potência ......................................................................................... 35


3.2 Conversores CC-CC ............................................................................................................ 36

3.2.1 Conversor Buck ........................................................................................................ 38

3.2.2 Conversor Boost ........................................................................................................ 40

3.2.3 Conversor Buck-Boost .............................................................................................. 42

3.2.4 Conversor Flyback (Buck-Boost isolado) ................................................................. 44

3.2.5 Conversor Forward (Buck isolado) .......................................................................... 46

3.2.6 Operação em Malha Fechada .................................................................................... 49

4 Segurança de Hardware e suas Vulnerabilidades ................................................................. 50


xviii

4.2 Especificação de Sistema..................................................................................................... 51

4.3 Lógica Combinacional e Lógica Sequencial ....................................................................... 51

5 Segurança de Projeto................................................................................................................ 53


5.2 Propriedade Intelectual de Projeto Baseado em Reutilização ............................................. 54

5.3 Marca D’Água ..................................................................................................................... 56

5.4 Requisitos de Qualidade de uma Marca d’Água ................................................................. 57

5.5 Impressão Digital ................................................................................................................. 58

5.6 Medição de Hardware ......................................................................................................... 63

6 Metodologia de Projeto ............................................................................................................ 66


6.2 Domínios de Abstração ....................................................................................................... 66

6.3 Fluxo de Desenvolvimento do Circuito ............................................................................... 68

6.4 Controle Digital ................................................................................................................... 69

6.4.1 Considerações Iniciais .............................................................................................. 69

6.4.2 Controle Digital utilizando Circuitos Lógicos Combinacionais ............................... 69

6.4.3 Controle Digital com FPGA ..................................................................................... 70

6.5 Comparando os Sistemas em FPGA X ASIC ...................................................................... 71

6.6 Síntese .................................................................................................................................. 73

6.7 Simulação ............................................................................................................................ 74

6.8 Verificação e Validação dos Dados ..................................................................................... 75

6.8.1 Fluxo de Validação Funcional do Circuito ............................................................... 76

6.8.2 Testes de Caixa Branca e Caixa Preta ...................................................................... 77

6.9 Desafios da Validação ......................................................................................................... 79

6.9.1 Validação Baseada em Simulação ............................................................................ 81

6.9.2 Terminologia de Validação ....................................................................................... 83

6.9.3 Métricas de Validação e Qualidade .......................................................................... 83

xix

6.9.3.1 Granularidade ............................................................................................... 64

6.9.3.2 Produtividade .............................................................................................. 65

6.9.3.3 Eficácia ......................................................................................................... 65

6.9.3.4 Exaustão ...................................................................................................... 65

7 Descrição de Projeto de Hardware .......................................................................................... 87


7.2 Linguagem de Descrição de Hardware Verilog .................................................................. 87

7.3 Introdução ............................................................................................................................ 87

7.4 Descrição de Especificação (Propriedade Intectual) ........................................................... 89

7.5 Descrição de Entrada e Saída .............................................................................................. 90

7.6 Descrição de Comportamento de Integração ....................................................................... 91

7.7 Descrição de Integração....................................................................................................... 99

8 Descrição do Ambiente de Validação.................................................................................... 102

8.1 Validação Funcional .......................................................................................................... 102

8.2 Arquitetura do Ambiente de Verificação e Validação dos Dados ..................................... 102

8.3 E-RM (Metodologia de Reutilização e)............................................................................. 104

8.4 Resultado de Simulação..................................................................................................... 104

8.5 Validação Baseada em Testes Direcionados ..................................................................... 104

8.6 Tarefa Dirigida .................................................................................................................. 105

8.7 Validação Baseada em Testes de Restrição ....................................................................... 106

8.8 Ferramenta de Simulação do Ambiente............................................................................. 107

8.9 UART - Interface Serial .................................................................................................... 110

8.10 DRA - Acesso Direto aos Registros ................................................................................ 111

8.11 SS - Soft-Starter ............................................................................................................... 112

8.12 Estabilizador .................................................................................................................... 115

8.13 Somador ........................................................................................................................... 117

8.14 Detector de Borda ............................................................................................................ 118

xx

8.15 PID - Proporcional Integral Derivator ........................................................................... 118

8.16 PWM - Pulso com Modulador ......................................................................................... 121

9 Conclusões ............................................................................................................................... 123

9.1 Conclusão Final ................................................................................................................. 123

9.2 Trabalhos Futuros .............................................................................................................. 124

Referências bibliográficas ......................................................................................................... 126

Apêndice A ................................................................................................................................. 129

Apêndice B.................................................................................................................................. 190

21

1 Introdução

1.1 Considerações Iniciais

Surgidas no contexto de revolução informacional, a "Revolução Telemática" ou

Terceira Revolução Industrial [2], NTIC (Novas Tecnologias de Informação e Comunicação),

tais tecnologias e métodos para se comunicar foram desenvolvidos gradativamente desde a

segunda metade da década de 1970 e, principalmente, nos anos 1990. A imensa maioria delas

se caracteriza por agilizar, horizontalizar e tornar menos palpável (fisicamente manipulável) o

conteúdo da comunicação, por meio da digitalização e da comunicação em redes (mediada ou

não por computadores) para a captação, transmissão e distribuição das informações (texto,

imagem estática, vídeo e som). Considera-se que o advento dessas novas tecnologias (e a

forma como foram utilizadas por governos, empresas, indivíduos e setores sociais) possibili-

tou o surgimento da "sociedade da informação". Alguns estudiosos já falam da “sociedade do

conhecimento” para destacar o valor do capital humano na sociedade estruturada em redes

telemáticas. Sendo assim, o surgimento de novas tecnologias trouxe consigo novas ameaças e

um novo tipo de guerra.

Os produtos de tecnologia da informação e comunicação são fornecidos “no esta-

do em que se encontram”, com garantias limitadas e, no caso de softwares, licenças que ex-

cluem o fornecedor da responsabilidade por consequências de mau funcionamento ou falha. A

maioria dos Contratos de Licença de Usuário Final (EULA) é longa e difícil de entender por

um leigo, que tem que aceitar os termos e condições para instalar o software. Muitos dos apps

projetados para smartphones e tablets podem não ter garantia de qualidade adequada e alguns

foram solicitados a conter softwares mal intencionados, Malwares. Tal cenário intensifica a

necessidade de se verificar o funcionamento de sistemas digitais, como uma ferramenta que

provê a segurança da funcionalidade de sistemas digitais e analógicos, assegurando resultados

funcionais.

Para que a produção de um circuito integrado alcance a margem segura de funcio-

nalidade, é necessário utilizar-se de testes de estresse já na fase de projeto do circuito, com a

verificação e validação funcional de dados que, conforme [3], aumentou a complexidade dos

sistemas em escala exponencial devido à quantidade de ferramentas e recursos a serem utili-

22

zados. Portanto, metodologias de verificação funcional começaram a se destacar no ambiente

da arquitetura digital. Deste modo, a verificação funcional de validação de dados se torna uma

ferramenta de segurança fundamental para o desenvolvimento, implementação e construção

do hardware. Com essa ferramenta, o engenheiro de verificação tem uma probabilidade maior

de encontrar erros durante o desenvolvimento do projeto. Segundo alguns autores, estima-se

que cerca de 70% (setenta por cento) dos recursos destinados ao processo de construção do

hardware são gastos na verificação funcional.

Poucos foram os trabalhos realizados com pesquisas em verificação de dispositi-

vos com abordagem em metodologias seguras e funcionais, sendo apenas alguns estudos vis-

tos no domínio da verificação e validação funcional de dados [4]. Devido a esta falta de co-

nhecimento, mais pesquisas precisam ser feitas na área de segurança de hardware, abordando

a verificação funcional e validação de dados como uma ferramenta para a segurança de hard-

ware, a fim de encontrar falhas evitando possíveis ameaças e agindo como contramedidas

seguras e funcionais. A este respeito, o trabalho aqui apresentado visa à relevância da metodo-

logia eRM como uma ferramenta que proporciona segurança de hardware, executando a real

funcionalidade do circuito, tendo como objetivo descobrir falhas de codificação que podem

gerar alterações na saída do circuito, executando determinadas funções e procedimentos de

forma errada, podendo pôr em risco a produção de resultados de sistemas digitais em relação

à funcionalidade do circuito.

Com o devido valor, a metodologia de reutilização e reaproveitamento de código

eRM surge como importante elemento para satisfazer as exigências de tempo e mercado. O

projetista deve ser capaz de reutilizar a propriedade intelectual no projeto, como modelo de

referência. Tal reutilização do ambiente de verificação em diferentes projetos economiza tem-

po e melhora a qualidade do projeto de verificação.

1.1.1 Estrutura da Dissertação

O ponto de partida deste trabalho é a utilização de um sistema de controle de ten-

são do tipo Buck, o planejamento na construção do circuito digital com base em um dispositi-

vo com características de baixo consumo de energia, oferecendo como contribuição ao desen-

volvimento do circuito digital a metodologia eRM como uma ferramenta segura de verifica-

ção e validação de dados com a intenção de se alcançarem elevados níveis de confiabilidade

do circuito. Assim, este trabalho será estruturado da seguinte maneira:

23

Capítulo 1: Introdução, considerações iniciais, objetivos e contribuições e es-

truturação da dissertação.

Capítulo 2: Circuitos Integrados; apresenta uma intodução sobre o desenvol-

vimento de CIs, setores da indústria, tipos diferentes de CIs, evolução e diferentes

tipos de aplicações, novos CIs. Os diferentes CIs de propósito geral e de propósito

específico também são descritos e são citados alguns exemplos. A opção pelo con-

trole digital através de um DSP (processador de sinais digitais) ou de FPGA (ma-

trizes de portas digitais reprogramáveis) é abordada.

Capítulo 3: Sistemas de eletrônica de potência; apresenta a estrutura de potên-

cia utilizada para simular a metodologia, suas características e formas de controle.

A estrutura de potência a ser utilizada é um conversor de CA (corrente alternada)

para CC (corrente contínua), abaixador de tensão, também conhecido como

BUCK. Existem, basicamente, duas formas de controle do BUCK: o controle ana-

lógico e o controle digital.

Capítulo 4: Segurança de hardware e suas vulnerabilidades; apresenta primei-

ramente a relevância da segurança de hardware, pontos significativos quanto à

confiança do circuito na cadeia de distribuição de microchips, risco de haver

backdoors no sistema, casos de projetistas que projetam sistemas utilizando IPs de

terceiros, casos que podem potencialmente introduzir vulnerabilidades de segu-

rança no sistema e casos de projetistas com intenções maliciosas e fundições ma-

liciosas que podem adicionar trojans de hardware no hardware.

Capítulo 5: Segurança de projeto; apresenta a forma como um projetista de

hardware ou uma empresa pode proteger sua IP (propriedade intelectual) de pro-

jeto contra uso indevido, alerta para alguns passos durante a fase de projeto, pro-

teção do projeto, apoio de proteção da lei e algumas técnicas disponíveis para pro-

teger propriedades intelectuais.

Capítulo 6: Metodologia de projeto; apresenta alguns conceitos tradicionais de

desenvolvimento de sistemas, construção de componentes elementares, como

portas lógicas e transistores, criação de linguagens, principais vantagens do uso

das HDLs, fluxo de projeto, comparativos entre FPGA e ASICS. A verificação

funcional e validação de dados com uma visão estratégica para testes funcionais

de IPs abordando a metodologia eRM como ferramenta fundamental para se

projetar CIs seguros e funcionais são uma das contribuições deste trabalho.

24

Capítulo 7: Descrição do projeto de hardware; apresenta um estudo sobre as

linguagens de descrição de hardware HDL(Hardware Description Language) que

podem descrever sistemas multidisciplinares com um mesmo formato ou padrão e

em um mesmo ambiente de simulação. A metodologia de desenvolvimento

através de linguagens de descrição de hardware pode ser feita através de vários

níveis de abstração e, em alguns casos, a descrição em HDLs pode ser diretamente

implementada no sistema com grande chance de êxito.

Capítulo 8: Descrição do ambiente de verificação e validação; apresenta a des-

crição do ambiente de testes, metodologia eRM como uma ferramenta fundamen-

tal para se conseguir testar a funcionalidade de IPs, linguagem e arquitetura de

testes, componentes de verificação e validação, checagem de dados e resultados

de simulação. A reutilização de código em verificação funcional para sistemas di-

gitais como estratégias de segurança.

Capítulo 9: Conclusões e trabalhos futuros; apresenta as conclusões e perspec-

tivas de trabalhos Futuros.

1.1.2 Objetivos e Contribuições

As contribuições deste trabalho podem ser declaradas como: (1) conhecimento de

um sistema de controle de tensão do tipo Buck; (2) projeto de hardware seguro; (3) vantagens

da metodologia eRM como uma ferramenta segura de validação e teste; (4) reutilização de

código, verificação funcional e validação dos dados como parte da segurança do sistema; (5)

resultados obtidos.

Como relevância, este trabalho apresenta a abordagem na metodologia eRM como

uma ferramenta segura na fase de projeto de hardware, a metodologia de verificação funcio-

nal de reutilização de código eRM, que se diferencia pela sua programação de códigos orien-

tada a aspectos tornando a validação e verificação funcional no domínio da programação ori-

entada a objetos. Possibilita a um engenheiro de software utilizar sua experiência com pro-

gramação de códigos, para se inserir no universo da indústria de circuitos integrados, assim

como físicos, matemáticos que possuem habilidades com a respectiva técnica de gerar códigos

e realizar testes capazes de localizar falhas em um circuito ainda em fase de projeto, realizan-

do a verificação funcional de um dispositivo de controle de tensão, utilizando ferramentas

computacionais, visando ao aumento da produtividade e eficiência de execução de testes dire-

25

cionados e aleatórios. A metodologia de verificação funcional eRM ( eReuse Methodology),

além de alta produtividade, proporciona um direcionamento na construção de componentes de

testes de circuitos digitais, sendo possível criar pontos de testes específicos com a finalidade

de verificar a real funcionalidade do sistema. Assim agrega-se valor ao circuito integrado,

devido ao aumento na segurança de seu funcionamento, atingindo, de fato, o que foi proposto

na especificação técnica do circuito integrado, além de oferecer qualidade na execução de

suas funcionalidades através de checagem de dados e checagem funcional em um mesmo am-

biente de teste de validação.

26

2 Circuitos Integrados


Conforme definição [5], um ASIC, Application Specific Integrated Circuits, é um

circuito integrado para ser aplicado com propósito específico.

A figura 1(a) mostra um pacote IC detalhando um arranjo de grade com pinos, ou

PGA, mostrando de cabeça para baixo os pinos, que passarão por buracos em uma placa de

circuito impresso. Geralmente chamam o pacote de chip, mas, como se pode ver na Figura

1.0 (b), o próprio chip de silício é montado na cavidade sob a tampa selada.

Figura 1 – Amostra de um Pacote do Chip [5]

Segundo [5], um pacote PGA é geralmente feito de um material cerâmico, mas os

pacotes de plástico também são comuns.

O tamanho físico de um molde de silício varia de poucos milímetros a mais de 1

(uma) polegada em um lado, mas em vez disso, geralmente medimos o tamanho de um IC

pelo número de portas lógicas ou pelo número de transistores que o IC contém. Como uma

unidade de medida equivalente pode-se ter uma porta NAND de duas entradas .

Muitas vezes se utiliza apenas o termo 'portas', em vez de portas equivalentes,

quando medimos o tamanho do chip. Não pode ser confundido com o terminal de porta de

um transistor. Por exemplo, um IC de 100 k-Gate contém o equivalente a 100.000 portas

NAND de duas entradas.

A indústria de semicondutores evoluiu dos primeiros IC do início dos anos 70 e

amadureceu rapidamente desde então. Os IC iniciais de SSI (integração em pequena escala)

continham algumas portas lógicas (1 a 10), portas NAND, portas NOR e assim por diante,

totalizando algumas dezenas de transistores. A era da integração de média escala (MSI) au-

27

mentou a gama de lógica integrada e disponível para contadores e funções lógicas semelhan-

tes e de maior escala. A era da LSI (integração em larga escala) embalou uma lógica ainda

maior de funções, como os primeiros microprocessadores, em um único chip. A era da VSLI

(integração em escala muito grande) agora oferece microprocessadores de 64 bits, completos,

com memória cache e unidades aritméticas de ponto flutuante bem acima de um milhão de

transistores em um único pedaço de silício. À medida que a tecnologia de processo CMOS

melhora, os transistores continuam a ficar menores e os IC retêm cada vez mais transistores.

Algumas regiões, especialmente no Japão, usavam o termo ULSI (integração de escala ultra-

larga), mas a maioria das regiões utiliza o termo VLSI.

Os CI mais antigos usavam a tecnologia bipolar e a maioria dos IC lógicos usa-

vam TTL (lógica transistorizada de transistor) ou ECL (lógica acoplada por emissor). Embora

inventado antes do transistor bipolar, o MOS (transistor de metal óxido de silício) foi inicial-

mente difícil de fabricar devido a problemas com a interface de óxido. Como esses problemas

foram gradualmente resolvidos, a tecnologia MOS (nMOS ou NMOS) do metal-gate n-

channel, que se desenvolveu na década de 1970 [5], exigia menos etapas de mascaramento

naquela época, era mais densa e consumia menos energia do que os IC bipolares equivalentes.

Isso significava que, para um determinado desempenho, um IC MOS era mais barato que um

IC bipolar, o que levou ao investimento e crescimento do mercado de CI, MOS.

No início dos anos 80, as portas de alumínio dos transistores foram substituídas

por portas de polissilício, mas o nome MOS permaneceu. A introdução do polissilício como

material de porta foi uma grande melhoria na tecnologia CMOS, tornando mais fácil a fabri-

cação de dois tipos de transistores, sendo transistores MOS de canal-n e canal-p, no mesmo

CI, CMOS (MOS complementar) tecnologia. A principal vantagem do CMOS sobre o NMOS

é o menor consumo de energia. Outra vantagem de uma porta de polissilício foi a simplifica-

ção do processo de fabricação, permitindo que os dispositivos fossem reduzidos em tamanho.

Existem quatro transistores CMOS em uma porta NAND de duas entradas (e tam-

bém numa porta NOR de duas entradas), portanto, para se fazer a conversão entre portas e

transistores, multiplica-se o número de portas por 4 (quatro), para obter o número de transisto-

res. Também podemos medir um CI pelo menor tamanho de recurso (aproximadamente meta-

de do comprimento do menor transistor) impresso no CI. As dimensões do transistor são me-

didas em mícron (um mícron, é um milionésimo de metro). Assim, um circuito integrado de

0,5 mícrons ou dizem que este é construído em um, ou com processo de 0,5 mícrons, o que

significa que os transistores mais pequenos têm 0,5 mícrons de comprimento obtendo um ró-

tulo especial, de l ou lambda, para este de menor tamanho de recurso.

28

Um processo CMOS submícron é tão moderno e complicado quanto um processo

bipolar submicrométrico ou BiCMOS (uma combinação de bipolar e CMOS). No entanto, os

CMOS CI estabeleceram uma posição dominante, sendo fabricados em volume muito maior

do que qualquer outra tecnologia e, portanto, devido à economia de escala, o custo de CMOS

IC é menor do que um bipolar ou BiCMOS IC para a mesma função. O bipolar e BiCMOS IC

são usados para necessidades especiais. Por exemplo, a tecnologia bipolar geralmente é capaz

de lidar com tensões mais altas que o CMOS. Isso torna os IC bipolares e BiCMOS úteis em

eletrônica de potência, carros, telefone, circuitos e assim por diante.

Alguns IC de lógica digital e seus equivalentes analógicos (conversores analógi-

cos/digitais, por exemplo), são peças padrão ou IC padrão. Pode-se selecionar IC padrão de

catálogos e livros de dados e comprá-los de distribuidores. Fabricantes e projetistas de siste-

mas podem usar a mesma peça padrão em uma variedade de diferentes sistemas microeletrô-

nicos (sistemas que usam microeletrônica ou IC).

Com o advento do VLSI na década de 1980, os engenheiros começaram a perce-

ber as vantagens de projetar um IC personalizado ou adaptado a um determinado sistema ou

aplicativo, em vez de usar somente IC padrão. O design de sistemas microeletrônicos, em

seguida, torna-se uma questão de definir as funções que se podem implementar usando IC

padrão e, em seguida, implementar as funções lógicas restantes com um ou mais IC personali-

zados. Com o VLSI tornou-se possível construir um sistema a partir de um número menor de

componentes, combinando muitos IC padrão em alguns IC personalizados. Construir um sis-

tema microeletrônico com menos IC permite reduzir custos e melhorar a confiabilidade.

Naturalmente, há muitas situações em que não é apropriado usar um IC personali-

zado para cada parte de um sistema microeletrônico. Precisando-se de uma grande quantidade

de memória, por exemplo, ainda é melhor usar um IC de memória padrão, DRAM (memória

de acesso aleatório dinâmica) ou SRAM estática (RAM estática ou sRAM), em conjunto com

IC's personalizados.

Uma das primeiras conferências a serem dedicadas a este segmento emergente da

indústria de IC foi a CICC IEEE (Conferência Customizada de Circuitos Integrados), e os

procedimentos desta conferência anual formaram uma referência útil para o desenvolvimento

de IC personalizados. À medida que tipos diferentes de IC personalizados começaram a evo-

luir para diferentes tipos de aplicações, esses novos IC deram origem a um novo termo.

Os circuitos integrados de propósito geral [5], que não são ASIC, incluem peças

padrão, como: chips de memória vendidos como ROMs, itens de commodity, DRAM e S-

RAM, microprocessadores; IC equivalentes a TTL ou TTL nos níveis SSI, MSI e LSI.

29

ASICS, circuitos integrados de propósito específico [5], incluem: um chip para

um urso de brinquedo que fala; um chip para um satélite; um chip projetado para manipular a

interface entre a memória e um microprocessador para uma CPU da estação de trabalho; e um

chip contendo um microprocessador como uma célula junto com outra lógica.

2.2 Tipos de ASIC

Os IC são feitos em uma fina bolacha de silício circular, com cada bolacha con-

tendo centenas de matrizes (às vezes é usado dado ou dados para o plural de matrizes). Os

transistores e fiação são feitos de várias camadas (geralmente entre 10 e 15 camadas distintas)

construídas umas sobre as outras. Cada camada de máscara sucessiva tem um padrão que é

definido usando uma máscara semelhante a um slide fotográfico de vidro. A primeira meia

dúzia de camadas define os transistores. A última meia dúzia de camadas define os fios de

metal entre os transistores (a interconexão). Um IC personalizado completo inclui algumas

(possivelmente todas) células lógicas personalizadas e todas as camadas de máscara persona-

lizadas. Um microprocessador é um exemplo de um designer de IC totalmente personalizado

que gasta muitas horas aproveitando ao máximo cada mícron quadrado do espaço do chip do

microprocessador disponível. A personalização de todos os recursos do IC dessa maneira

permite que os designers incluam circuitos analógicos, células de memória otimizadas ou es-

truturas mecânicas em um IC, por exemplo. IC personalizados são os mais caros para fabricar

e projetar. O tempo de fabricação (o tempo necessário para fazer um IC não inclui o tempo de

design) é geralmente de oito semanas para um IC totalmente personalizado. Esses IC custo-

mizados completos geralmente são destinados a um aplicativo específico, chamando alguns

deles de ASICs customizados [5].

Os ASIC customizados que mais interessam são ASICs semicustos, para os quais

todas as células lógicas são pré-projetadas e algumas (possivelmente todas) camadas de más-

cara são customizadas. O uso de células pré-projetadas de uma biblioteca de células facilita o

projeto. Existem dois tipos de ASIC semicomponentes que abordaremos: ASIC baseados em

células padrão e ASIC baseados em array de gate. Em seguida, descreveremos os ASIC pro-

gramáveis, para os quais todas as células lógicas são pré-projetadas e nenhuma das camadas

de máscara é personalizada. Existem dois tipos de ASIC programáveis: o dispositivo lógico

programável e, o mais novo membro da família ASIC, o sistema de portas programáveis em

campo.

30

2.2.1 ASIC totalmente Customizados

Em um ASIC totalmente personalizado, um engenheiro projeta algumas ou todas

as células lógicas, circuitos ou layout especificamente para um ASIC. Isso significa que o

projetista abandona a abordagem de usar células pré-testadas e pré-caracterizadas para todo

ou parte desse design. Faz sentido adotar esta abordagem, somente se não houver bibliotecas

de células disponíveis que podem ser usadas para todo o design. Isso pode ocorrer, porque as

bibliotecas de células existentes não são rápidas o suficiente ou as células lógicas não são pe-

quenas o suficiente ou consomem muita energia. Você pode precisar usar um design persona-

lizado, se a tecnologia ASIC for nova ou tão especializada que não haja bibliotecas de células

existentes, ou porque o ASIC é tão especializado que alguns circuitos devem ser personaliza-

dos. Cada vez menos IC personalizados estão sendo projetados, devido aos problemas com

essas partes especiais do ASIC [5].

Historicamente, a tecnologia bipolar tem sido usada para funções analógicas de

precisão. Segundo [5], existem algumas razões fundamentais para isso e, em todos os circui-

tos integrados, a correspondência das características dos componentes entre os chips é muito

fraca, enquanto a correspondência das características entre os componentes no mesmo chip é

excelente. Suponha-se que foram encontrados os seguintes transistores T1, T2 e T3 em um

ASIC analógico/digital. Os três transistores são todos do mesmo tamanho e são construídos de

maneira idêntica.

Os transistores T1 e T2 estão localizados adjacentes entre si e têm a mesma orien-

tação. O transistor T3 tem o mesmo tamanho de T1 e T2, mas está localizado no outro lado do

chip e tem uma orientação diferente. IC são feitos em lotes chamados lotes de bolachas, wa-

fer. Um lote de bolacha é um grupo de bolachas de silício que são processadas em conjunto.

Geralmente há entre 5 e 30 bolachas em lote. Cada wafer pode conter dezenas ou centenas de

chips, dependendo do tamanho do IC e da bolacha.

2.2.2 ASIC Baseados em Célula Padrão

Um ASIC baseado em célula (IC baseado em célula, ou CBIC, um termo comum

no Japão, pronunciado sea-bick) usa células lógicas pré-projetadas (portas AND, portas OR,

multiplexadores e flip-flops, por exemplo), conhecidas como células padrão. Poderíamos apli-

31

car o termo CBIC a qualquer IC que use células, mas é geralmente aceito que um ASIC ou

CBIC baseado em célula significa um ASIC baseado em célula padrão.

As áreas de célula padrão (também chamadas de blocos flexíveis) em uma CBIC

são construídas de linhas de células padrão como uma parede construída de tijolos. As áreas

de célula padrão podem ser usadas em combinação com células maiores pré-projetadas, talvez

microcontroladores ou até mesmo microprocessadores, conhecidos como megacélulas. As

megacells também são chamadas de megafunctions, blocos personalizados completos, SLMs

(macros no nível do sistema), blocos fixos, núcleos ou FSB, Functional Standard Blocks.

O projetista ASIC define apenas o posicionamento das células padrão e a interco-

nexão em uma CBIC. No entanto, as células padrão podem ser colocadas em qualquer lugar

do silício. Isso significa que todas as camadas de máscara de uma CBIC são personalizadas e

exclusivas de um determinado cliente. A vantagem dos CBIC, segundo [5], é que os projetis-

tas economizam tempo, dinheiro e reduzem o risco usando uma biblioteca de células padrão

pré-projetada, pré-testada e pré-caracterizada. Além disso, cada célula padrão pode ser otimi-

zada individualmente. Durante o projeto da biblioteca de células, todo e qualquer transistor

em cada célula padrão pode ser escolhido para maximizar a velocidade ou minimizar a área,

por exemplo. As desvantagens são o tempo ou a despesa de projetar ou comprar a biblioteca

de células padrão e o tempo necessário para fabricar todas as camadas do ASIC para cada

novo design.

2.2.3 ASIC Baseados em Matriz de Portas

Em um array de portas ou ASIC baseado em array de portas [5], os transistores

são predefinidos na placa de silício. O padrão predefinido de transistores em um array de gate

é o array base, e o menor elemento que é replicado para fazer o array base (como um desenho

de MC Escher ou tiles em um floor) é a célula base (às vezes chamada de primitiva) . Apenas

as poucas camadas superiores de metal, que definem a interconexão entre os transistores, são

definidas pelo projetista usando máscaras personalizadas. Para distinguir esse tipo de gate

array de outros tipos, é geralmente chamado de MGA Masked Gate Array. O projetista o

escolhe de uma biblioteca de matriz de portas de células lógicas pré-projetadas e pré-

caracterizadas. As células lógicas em uma biblioteca de gate-array são frequentemente cha-

madas de macros. A razão para isso é que o layout da célula base é o mesmo para cada célula

lógica, e somente a interconexão (dentro das células e entre as células) é personalizada, de

32

modo que existe uma semelhança entre as macros de gate-array e uma macro de software. Na

IBM, [5] As macros gate-array, são conhecidas como livros (para que os livros façam parte

de uma biblioteca), mas este termo descritivo não é muito usado por outras companhias de

manufatura.

Podemos concluir as etapas de difusão que formam os transistores e, depois, ar-

mazenar as bolachas (às vezes chamamos uma matriz de gate de uma matriz predifusiva por

esse motivo). Como somente as interconexões de metal são exclusivas de um MGA, podemos

usar as wafers armazenadas para diferentes clientes, conforme necessário. Usar wafers pré-

fabricados até as etapas de metalização reduz o tempo necessário para fazer um MGA, o tem-

po de retorno, para alguns dias ou no máximo duas semanas. Os custos de todas as etapas ini-

ciais de fabricação de uma MGA são compartilhados para cada cliente e isso reduz o custo de

uma MGA em comparação a um projeto ASIC totalmente personalizado ou de célula padrão.

2.3 Matriz de Portas Estruturadas

Um gate array incorporado ou um array de gate estruturado [5] combina alguns

dos recursos de CBIC e MGA. Uma das desvantagens do MGA é a célula base do array de

gate fixo. Isso torna a implementação da memória, por exemplo, difícil e ineficiente. Em um

array de gate embutido, reservamos parte da área de IC e a dedicamos a uma função específi-

ca. Esta área incorporada pode conter uma célula base diferente que é mais adequada para

construir células de memória, ou pode conter um bloco de circuito completo, como um micro-

controlador.

Uma matriz de gate integrada oferece a eficiência aprimorada da área e o aumento

do desempenho de uma CBIC, mas com o custo mais baixo e o retorno mais rápido de uma

MGA. Uma desvantagem de um array de gate embutido é que a função incorporada é fixa.

Por exemplo, se uma matriz de portas incorporadas contiver uma área reservada para uma

memória de 32 k bits, mas onde se precisa apenas de uma memória de 16 k bits, talvez seja

necessário gastar metade da memória incorporada. No entanto, isso ainda pode ser mais efici-

ente e mais barato do que implementar uma memória de 32 k bits usando macros em uma

matriz SOG.

Os fornecedores de ASIC podem oferecer várias estruturas de gate array incorpo-

radas contendo diferentes tipos e tamanhos de memória, bem como uma variedade de funções

incorporadas. As empresas ASIC que desejam oferecer uma ampla gama de funções incorpo-

33

radas devem garantir que clientes suficientes usem cada gate array integrado para oferecer

vantagens de custo em relação a um gate array customizado ou CBIC.

2.4 Dispositivos Lógicos Programáveis

PLD (dispositivos lógicos programáveis) são IC padrão que estão disponíveis em

configurações padrão, a partir de um catálogo de peças, e são vendidos em volume muito alto

para muitos clientes diferentes. No entanto, os PLD podem ser configurados ou programados

para criar uma peça personalizada para um aplicativo específico e, portanto, também perten-

cem à família de ASIC. Os PLD usam diferentes tecnologias para permitir a programação do

dispositivo [5].

2.5 Matrizes de Portas Programáveis em Campo

Um passo acima do PLD em complexidade é o array de gate programável em

campo (FPGA). Há pouca diferença entre um FPGA e um PLD; um FPGA é geralmente mai-

or e mais complexo que um PLD. De fato, algumas empresas que fabricam ASIC programá-

veis chamam seus produtos de FPGAs e alguns chamam de PLD complexos. Os FPGA são o

mais novo membro da família ASIC e estão crescendo rapidamente em importância, substitu-

indo o TTL em sistemas microeletrônicos. Embora um FPGA seja um tipo de array de gate,

não se considera o termo gate-array baseados em ASIC para incluir FPGA. Isso pode mudar,

conforme os FPGA e MGA comecem a ser mais parecidos [5].

As características essenciais de um FPGA:

Nenhuma das camadas de máscara é personalizada.

Um método para programar as células lógicas básicas e a interconexão.

O núcleo é uma matriz regular de células lógicas básicas programáveis que po-

dem implementar lógica combinacional e sequencial (flip-flops).

Uma matriz de interconexão programável envolve as células lógicas básicas.

Células de E/S programáveis circundam o núcleo.

Os FPGA (Field Programmable Gate Arrays) são dispositivos versáteis que per-

mitem que uma função seja implementada, mapeando-a na lógica (recursos) pré-existente do

FPGA. O mapeamento é referido como sua configuração. Dispositivos FPGA podem ser sen-

34

síveis a eventos únicos (SEU) e outras falhas, devido à ionização de partículas em sua confi-

guração e em sua lógica pré-existente. Na eletrônica, estratégias de mitigação foram desen-

volvidas para abordar ambas as preocupações. Alguns fornecedores de FPGA implementam

estruturas de dispositivos reforçadas (redes de roteamento, relógios, flip-flops e configura-

ção). Esses dispositivos geralmente têm velocidades funcionais de sistema de até 350 MHz e

são configuráveis uma única vez. Outros fornecedores da FPGA estão criando dispositivos

comerciais com vantagens como: menor custo, menor voltagem do núcleo, velocidades de

sistema de até 500 MHz, reconfigurabilidade e maior disponibilidade de recursos. No entanto,

a inserção desses dispositivos comerciais prontos para uso (COTS) em aplicativos críticos do

sistema pode exigir a inclusão de circuitos para mitigar problemas de configuração e lógica e,

assim, aumentar a complexidade do design geral.

O desenvolvimento de projetos ASIC (Application Specific Integrated Circuits),

se comparado à tecnologia de dispositivos FPGA (Field Programmable Gate Array), perde

devido ao alto custo na fabricação quando em baixa demanda, sendo vantajoso somente para

uma alta demanda. Não foi mencionado ainda que dispositivos ASIC não ofereçam nenhum

conjunto de ferramentas, ficando esta responsabilidade para quem vai montar e vender o pro-

duto final. Em FPGA ou ASIC, o desenvolvimento de circuitos digitais é produzido através da

linguagem de descrição de hardware Verilog ou VHSIC, sendo ambas muito utilizadas tanto

no meio industrial e principalmente acadêmico. Citando novamente uma das grandes vanta-

gens na utilização de FPGA, são os conjuntos de ferramentas de software visuais, como gera-

dores de sistemas que possibilitam a comunicação entre dispositivos construídos em FPGA

por dispositivos desenvolvidos, dentre esses o Simulink que possibilita a modelagem de dis-

positivos utilizando recursos e funções aritméticas e lógicas. Esses recursos incluem disposi-

tivos dedicados DSP (Digital Signal Processor), multiplicadores, memórias de porta dupla,

tabelas de pesquisa, LUT, registros, buffers tri-state, multiplexadores e controladores de reló-

gio digital. Além disso, FPGA contém mecanismos sofisticados de entrada e saída que podem

lidar com uma ampla gama de requisitos de largura de banda e de tensão. Em computação os

dispositivos de entrada e saída são interconectados por um conjunto de fios e controlados por

barramentos que atendem às requisições dos dispositivos de forma hierárquica.

35

3 Sistemas de Eletrônica de Potência


Os setores industriais, militares e comerciais vêm apresentando, cada vez mais,

equipamentos eletrônicos que proporcionam maior comodidade e eficiência. Entretanto al-

guns equipamentos eletrônicos apresentam cargas não lineares, proporcionando uma relação

não linear entre a tensão e a corrente da rede [6]. Estes equipamentos drenam da rede elétrica

correntes não sinoidais, que provocam uma série de problemas nas instalações, assim como

para os sistemas de distribuição e transmissão, tais como[7] [8]:

Baixo fator de potência;

Distorção da tensão da rede no ponto de acoplamento comum, devido à impe-

dância do circuito ou da instalação;

Baixa eficiência;

Interferência em alguns instrumentos e equipamentos.

Existem algumas soluções preventivas para diminuir, ou até mesmo eliminar, os

efeitos destas cargas não lineares (equipamentos eletrônicos) conectados ao sistema elétrico,

entre as quais a utilização de equipamentos que apresentem uma característica resistiva para a

rede ou uma baixa distorção harmônica de corrente [8] [7]. Uma dessas soluções preventivas é

o conversor estático tipo BUCK [9], que pode ser usado com um pré-regulador de fator de

potência elevado. Ele é formado por três etapas: o estágio de retificação e filtragem, o conver-

sor BUCK e um controle através de modulação por largura de pulso PWM, Pulse Width Mo-

dulation. O conversor BUCK é um conversor abaixador que tem como característica principal

a diminuição da tensão média de saída em relação ao seu valor de pico da entrada. O BUCK

vem sendo muito utilizado, pois com o mesmo pode-se obter uma correção do fator de potên-

cia para muito próximo da unidade possuindo proteção contra curto-circuito e inexistência de

corrente de partida excessiva. O conversor abaixador CC/CC é formado por três estágios con-

forme ilustrado na figura 2.

36

Figura 2 - Estágios do Conversor Tipo Buck [10]

3.2 Conversores CC-CC

Conversores CC-CC são sistemas formados por semicondutores de potência, ope-

rando como interruptores, e por elementos passivos, normalmente indutores e capacitores, que

têm por função controlar o fluxo de potência de uma fonte de entrada para uma fonte de saída

[11].

A figura 3 mostra o diagrama elétrico e a forma de onda da tensão de saída de

um conversor CC-CC básico.

Figura 3 - Conversor CC-CC e Forma de Onda da Tensão de Saída [12]

O intervalo de comutação é definido como:

(1)

Fs é a frequência de comutação [11]. Esta frequência tende a ser a mais alta possí-

vel, diminuindo assim o volume dos elementos magnéticos e capacitivos do conversor.

Vi Ro

S

+

-

Vo

Vo

Vi

Ton Ts

37

A razão entre o intervalo de comutação (Ts) e o intervalo de condução do interrup-

tor S (Ton) é definido por razão cíclica e dada por:

(2)

A tensão média na saída deste conversor é calculada por:

(3)

Usando Ton = DTs , tem-se:

(4)

A relação entre a tensão de saída e a tensão de entrada é definida por ganho estáti-

co do conversor e dada então por:

(5)

Pelo gráfico mostrado na figura 4, nota-se que a variação da tensão de saída com a

razão cíclica é linear.

Figura 4 - Ganho Estático em Função de D [12]

Os sinais de comando do interruptor podem ser gerados com frequência de comu-

tação fixa ou variável [11]. Uma forma de gerar os sinais de comando com frequência fixa é

através de modulação por largura de pulso (PWM). Na figura 5, mostra-se uma forma simples

de realizar PWM.

0 0,25 0,5 0,75 10

0,25

0,5

0,75

1

D

Vo/Vi

i

o

V

VD

38

Figura 5 - Exemplo de um Circuito PWM [12]

3.2.1 Conversor Buck

O conversor Buck é um conversor abaixador de tensão [11], caracterizado por ter

entrada em tensão e saída em corrente. Na figura 6, mostra-se o diagrama elétrico do conver-

sor Buck.

Figura 6 - Conversor Buck [12]

As etapas de funcionamento do conversor Buck são descritas a seguir.

1ª Etapa (0, DTs): S está conduzindo. A corrente circula por Lo e pela saída. Nes-

ta etapa, Vi fornece energia para a saída e para a magnetização do indutor Lo.

2ª Etapa (DTs, (1-D)Ts): S está bloqueado. No instante de abertura de S, o diodo D

entra em condução. A energia do indutor é transferida para a carga, isto é, o indutor é des-

magnetizado.

A forma de onda da tensão Vab é mostrada na Figura 7.

VCC

+

-

Gerador

de

Rampa VcVg

Vr

Ton Ts

Vc

Ton Ts

D

Lo

RoCoVi

S a

b

+

-

Vo

39

Figura 7 - Forma de Onda da Tensão [12]

Como a tensão média sobre o indutor deve ser nula [11], então:

Vo = Vab_med =

= D (6)

A Figura 8 mostra a variação da tensão de saída em função da razão cíclica para o

conversor Buck.


As principais formas de onda do conversor Buck são mostradas na figura 9.

Figura 9 - Principais formas de onda do conversor Buck [12]

O conversor Buck pode operar em três modos:

Vab

Vi

DTs Ts

0 0,25 0,5 0,75 10

0,25

0,5

0,75

1

D

Vo/Vi

VLo

ILo

VCo

VS

VD

Vi-Vo

-Vo

Io

Vi

-Vi

D Ts Ts

40

1º - Condução Contínua: A corrente em Lo não se anula durante um período de

comutação;

2º - Condução Descontínua: A corrente em Lo se anula a cada período de comuta-

ção;

3º - Condução Crítica: A corrente em Lo está no limiar de se anular a cada período

de comutação.

As principais características do conversor Buck são [11]:

Pode apenas diminuir a tensão na saída;

A corrente de saída tem boa qualidade;

A corrente na entrada é descontínua.

3.2.2 Conversor Boost

O conversor Boost é um conversor elevador de tensão [11], caracterizado por ter

entrada em corrente e saída em tensão. Na figura 10 mostra-se o diagrama elétrico do conver-

sor Boost.

Figura 10 - Conversor Boost [12]

As etapas de funcionamento do conversor Boost são descritas a seguir.

1ª Etapa (0, DTs): S está conduzindo. O indutor L é magnetizado. A fonte Vi for-

nece energia ao indutor.

2ª Etapa (DTs, (1-D)Ts): S está bloqueado. O diodo D entra em condução. A fonte

Vi e o indutor L fornecem energia à saída. A tensão na carga aumenta.

A forma de onda da tensão sobre o indutor é mostrada na figura 11.

L

Co

D

Vi Ro

S

+

-

Vo

41

Figura 11 - Tensão sobre o Indutor [12]

Como a tensão média sobre o indutor deve ser nula [11], então:

(7)

A figura 12 mostra a variação da tensão de saída em função da razão cíclica para o

conversor Boost.


As principais formas de onda do conversor Boost são mostradas na figura 13.

Figura 13 - Principais Formas de Onda do Conversor Boost [12]

Vi

VL

TsDTs

-(Vo-Vi)

0 0,25 0,5 0,75 10

25

50

75

100

D

Vo/Vi

VLo

ILo

VCo

VS

VD

Vi-Vo

-Vo

Io

Vi

-Vi

D Ts Ts

42

As principais características do conversor Boost [11] são:

Pode apenas aumentar a tensão na saída;

A corrente de saída é descontínua;

A corrente na entrada tem boa qualidade.

3.2.3 Conversor Buck-Boost

O conversor Buck-Boost é um conversor que pode operar como abaixador ou ele-

vador de tensão [11], caracterizado por ter entrada em tensão e saída em tensão. Na figura 14,

mostra-se o diagrama elétrico do conversor Buck-Boost.

Figura 14 - Conversor Buck-Boost [12]

As etapas de funcionamento do conversor Buck-Boost são descritas a seguir.

1ª Etapa (0, DTs): S está conduzindo. A fonte Vi fornece energia para a magneti-

zação do indutor L.

2ª Etapa (DTs, (1-D)Ts): S está bloqueado. A energia do indutor L é transferida

através do diodo D para a saída. O indutor L é desmagnetizado.

A forma de onda da tensão sobre o indutor é mostrada na figura 15.

Figura 15- Tensão no Indutor [12]

Como a tensão média sobre o indutor deve ser nula, então:

L Co

D

RoVi

S

+

-

Vo

L Co

D

RoVi

S

+

-

Vo

43

(8)

Na figura 16 mostra-se a variação da tensão de saída, em função da razão cíclica

para o conversor Buck-Boost.


As principais formas de onda do conversor Buck-Boost são mostradas na figura

17.

Figura 17 - Principais Formas de Onda do Conversor Buck-Boost [12]

As principais características do conversor Buck-Boost [11] são:

É um conversor à acumulação de energia;

Pode operar como elevador ou abaixador;



0 0,25 0,5 0,75 10

2,5

5

7,5

10

D

Vo/Vi

VLo

ILo

ICo

VS

VD

VCo

D Ts Ts

Vi

-Vo

Io

Vo

Vi+Vo

-(Vi+Vo)

44

3.2.4 Conversor Flyback (Buck-Boost isolado)

O conversor Flyback é um conversor idêntico ao conversor Buck-Boost [11], mas

que apresenta isolação galvânica entre a tensão de entrada e de saída. A figura 18 mostra o

diagrama elétrico do conversor Flyback, bem como a sequência de passos para obter o con-

versor Flyback do conversor Buck-Boost.

Figura 18 - Conversor Flyback [12]

As etapas de funcionamento do conversor Flyback são descritas a seguir.

1ª Etapa (0, DTs): S está conduzindo. A fonte Vi fornece energia para a magneti-

zação do enrolamento primário do transformador. O diodo D está reversamente polarizado.

2ª Etapa (DTs, (1-D)Ts): S está bloqueado. A energia armazenada no transforma-

dor é levada para a saída através do diodo D.

A forma de onda da tensão no primário do transformador é mostrada na figura 19.

Figura 19 - Tensão no Primário [12]

Como a tensão média sobre enrolamento primário do transformador deve ser nula,

então:

L Ro

D

Vi Co Co RoVi Lpri

D

Lsec

RoCo

D

LpriVi Lsec Lsec

D

RoCoLpriVi

BUCK-BOOST

S S

Qual a polaridade do transformador??

S

-

Vo Vo

S

+

-+

?

?

n:1

n:1

n:1

Vi

Vpri

TsDTs

-nVo

45

(9)

Chamando tem-se:

(10)

A tensão Vo’ é a tensão de saída referida ao lado primário. Na figura 20 mostra-se a

variação da tensão de saída em função da razão cíclica para o conversor Flyback.


A vantagem do uso de um transformador pode ser vislumbrada através de um exemplo

[11]. Suponhamos um conversor Buck-Boost com tensão de entrada de 100V e tensão deseja-

da na saída de 12V. A razão cíclica nominal seria:

(11)

Esta razão cíclica é bastante baixa para operação em malha fechada [11]. Usando um

transformador, ou seja, um conversor Flyback no lugar do conversor Buck-Boost, pode-se

escolher a razão cíclica nominal e em seguida adaptar as tensões através da relação de trans-

formação. Escolhendo então uma razão cíclica nominal de 0,3 vem:

0 0,25 0,5 0,75 10

2,5

5

7,5

10

D

Vo'/Vi

107,010012

12

VV

VD

oi

on

ss T)D1(

0

o

s

TD

0

i

s

dtnVT

1dtV

T

1

D1

D

V

nV

i

o

'oo VnV

D1

D

V

V

i

'o

46

(12)

As principais formas de onda do conversor Flyback são mostradas na Figura 21.

Figura 21 - Principais Formas de Onda do Conversor Flyback [12]

As principais características do conversor Flyback [11] são:

É um conversor à acumulação de energia;

A saída é isolada da entrada;

Permite ajustar a razão cíclica de operação através da relação de trans-

formação;

Possibilita usar várias saídas;

Pode operar como elevador ou abaixador;



3.2.5 Conversor Forward (Buck isolado)

O conversor Forward é um conversor idêntico ao conversor Buck [11], mas que

apresenta isolação galvânica entre a tensão de entrada e de saída. A figura 22 mostra o dia-

grama elétrico do conversor Forward, bem como a sequência de passos para obter o conver-

sor Forward do conversor Buck.

V86,423,01

3,0100

D1

DVV

n

ni

'o

57,312

86,42

V

Vn

o

'o

Vpri

Vsec

Ipri

VS

VD

Isec

D Ts Ts

Vi

-nVo

Vi+nVo

-(Vi/n+Vo)

Vo

-Vi/n

47

Figura 22- Conversor Forward [12]

As etapas de funcionamento do conversor Forward são descritas a seguir.

1ª Etapa (0, DTs): S está conduzindo. A fonte Vi fornece energia para a carga a-

través do transformador. O diodo D2 conduz e D1 e D3 estão bloqueados.

2ª Etapa (DTs, (1-D)Ts): S está bloqueado. O diodo D3 conduz a corrente da car-

ga. O transformador é desmagnetizado através diodo D1; esta energia é devolvida para a fonte

Vi.

A forma de onda da tensão no indutor é mostrada na figura 23.

Figura 23 - Tensão no Indutor [12]

Como a tensão média sobre o indutor deve ser nula, então:

Vi RoCo

Lo

D D RoCo

Lo

Vi LsecLpri

RoDLpriVi CoLsec

LoLdes

Vi

Lo

Lpri Ro

Ldes

Lsec D Co

Ddes

CoLsec

D1

Ldes

Lpri

Lo

Vi RoD3

D2

Co

Ldes

D1

Lo

Vi

Lsec

D2

Lpri D3 Ro

BUCK

S S

Como eliminar a energia armazenada devido à magnetizante??

S

Sempre teria corrente no enrolamento de desmagnetização!!

S

No secundário circularia uma corrente por D!!

S

S

+

-

Vo

Vi/n-Vo

VLo

TsDTs

-Vo

48

(13)

Chamando tem-se:

(14)

A tensão Vo’ é a tensão de saída referida ao lado primário [11]. A figura 24 mostra

a variação da tensão de saída em função da razão cíclica para o conversor Forward.


As principais formas de onda do conversor Forward são mostradas na figura 25.

No instante Tx, a desmagnetização do transformador está completa.

As principais características do conversor Forward [11] são:

É um conversor de transferência direta de energia;

A saída é isolada da entrada;

Permite ajustar a razão cíclica de operação através da relação de transforma-

ção;

Possibilita usar várias saídas;

Pode operar como abaixador, devido apenas à razão cíclica;

A corrente de saída é de boa qualidade;


ss T)D1(

0

o

s

TD

0

oi

s

dtVT

1dtV

n

V

T

1

DV

nV

i

o

'oo VnV

0 0,25 0,5 0,75 10

0,25

0,5

0,75

1

D

Vo'/Vi

49

Figura 25 - Principais Formas de Onda do Conversor Forward [12]

3.2.6 Operação em Malha Fechada

Para manter a tensão de saída, ou corrente de saída, no valor desejado e indepen-

dente das variações dos componentes da tensão de entrada e da carga, é necessário operar o

conversor em malha fechada. Operar em malha fechada significa ajustar a razão cíclica para

obter a tensão correta na saída, sempre que ocorrer alguma variação que possa desviar a ten-

são de saída do valor correto, por exemplo, variação da carga.

A figura 26 mostra o conversor Buck operando em malha fechada através da mo-

dulação por largura de pulso (PWM). O compensador deve ser estudado conforme a aplicação

e conforme as características de desempenho esperadas do sistema.

Figura 26 – Exemplo de Conversor em Malha Fechada [12]

Vpri

Vsec

Vdes

Ipri

Isec

Ides

D Ts Ts Tx

Vi

-Vi

Vi/n

-Vi/n

-Vi

Vi

D

Lo

RoVi Co R1

R2

+

-

R3

R4 C2

Vref

+

-

S

+

-

Vo

Vg

50

4 Segurança de Hardware e suas Vulnerabilidades


Em um fluxo de projeto ASIC, a execução inicial do produto parte de uma ideia

com base na necessidade e na demanda que o cliente fez ao contratar o projetista ou a casa de

projeto. Logo após essas ideias estarem no contexto da organização e no planejamento da e-

xecução, começa a se pensar na estruturação do projeto, sendo:

Especificação do Sistema;

Descrição do Hardware;

Verificação Funcional do Hardware como componente de segurança da fun-

cionalidade.

A especificação do sistema ou especificação do IP (Propriedade Intelectual) deve

fechar as possibilidades do projetista fazer algo que não esteja descrito no documento, dei-

xando a criatividade técnica para a criação do circuito, conforme especificação do sistema.

Após entendimento da especificação do projeto, o projetista inicia a descrição do

hardware através da linguagem de descrição de hardware, podendo ser Verilog ou VHDL,

seguindo rigorosamente o detalhamento funcional do circuito descrito na especificação.

Como garantia e segurança, a descrição do hardware construída pelo projetista

deve ser testada em nível funcional pelo engenheiro de verificação do sistema ou engenheiro

de verificação de IP, com a finalidade de garantir o funcionamento do circuito de forma segu-

ra e funcional.

Um projetista de hardware, por segurança, não pode e não deve confiar no hard-

ware que recebe, não importa se for um celular, laptop, desktop ou mesmo apenas um sistema

embarcado muito simples. Primeiramente, é relevante analisar alguns pontos quanto à confi-

ança na cadeia de fornecimento de microchips, podendo haver backdoors no servidor ou no

sistema. Há casos também de projetistas que planejam sistemas de terceiros que, além de uti-

lizar ferramentas de design, podem não vir de uma fonte confiável. Outra razão é quando as

pessoas projetam hardwares para implementar aplicações, implementar funções, por exem-

plo, Crypto Crimi, primitivos; neste caso, eles consideram o desempenho e não a segurança,

isso pode potencialmente introduzir vulnerabilidades de segurança no sistema e, finalmente,

podem existir projetistas maliciosos, fundições maliciosas, que podem adicionar trojans de

hardware ao hardware, além dessas questões relacionadas ao processo de design de hardwa-

51

re. O hardware em si pode se tornar um alvo para ataques, tais como análise de canal lateral e

ataques físicos.

Conforme um relatório de 2006 da agência de projetos de pesquisa avançada de

defesa dos Estados Unidos, o projeto vai de uma especificação de usuário, após passar por

uma equipe de projeto, para o fabricante e, eventualmente, é entregue de volta para o usuário

do sistema, com a finalidade de testes, implantação e monitoramento.

4.2 Especificação de Sistema

A especificação de um sistema é uma descrição de sua funcionalidade e outras ca-

racterísticas que são necessárias para o seu uso, então, quando as pessoas especificam siste-

mas digitais, normalmente eles vão de alto nível a baixo nível ou nível binário. Normalmente

eles recebem insumos do mundo real e o mundo real é analógico. O primeiro passo que pre-

cisa ser executado é a conversão de sinais analógicos para digital, em seguida, para sinais di-

gitais e, às vezes, pode ser necessário fazer a codificação [13].

Este processo envolve codificação, alimentação do circuito, processamento de si-

nais mistos, conversão de sinais, definiçõs de funções booleanas, pois esta é uma função que

determina, dadas as entradas, quais serão as saídas.

Normalmente, essas funções booleanas serão representadas como uma tabela da

verdade para lógica combinacional ou como uma máquina de estado, podendo às vezes ser

chamada de tabela de transição de estado ou de gráfico de transição do estado, estes são usa-

dos então para modelar sistemas de sincronia.

4.3 Lógica Combinacional e Lógica Sequencial

Por meio da segurança de hardware, é importante entender como ele é construído

primeiro e para isso é importante entender os fundamentos de projeto de lógica digital [14].

Portanto, o princípio básico é abordar a especificação de sistemas com um enfo-

que na segurança de hardware, implementar sistemas digitais seguros de acordo a sua especi-

ficação, otimizar suas limitações, citando, como exemplo, a lógica combinacional e o circuito

sequencial. Para demonstrar estes procedimentos e conceitos, é importante evitar colocar-se

52

em condições de risco, a fim de não causar vulnerabilidades de segurança, em termos de sín-

tese e otimização do sistema.

No entanto, quando usado corretamente, as condições de cuidado também não po-

dem fornecer uma oportunidade única de construir sistemas mais seguros e confiáveis, já que

um sistema pode ser visto como uma caixa preta, onde ele é enxergado como portas de entra-

da e saída gerada. O produto dessa relação é chamado de funcionalidade.

Para a lógica combinacional, sempre que executar a mesma combinação de entra-

da, haverá a mesma saída. Não importa quantas vezes se execute a lógica combinacional,

sempre que alimentar essa entrada para ela.

Para a lógica sequencial, o par de entradas e saída pode não ser único, o que signi-

fica que para a mesma entrada, sua saída pode não ser a mesma. Isso porque dentro de um

sistema sequencial, existe uma unidade chamada elemento de memória, em que a saída de-

pende da entrada e também do valor atual da unidade de memória, o que significa que a lógica

combinacional, dentro do circuito sequencial, levará entradas de saídas primárias e também,

internamente, das unidades de memória. Isso pode ser utilizado para avaliar qual será a saída

e, enquanto isso, ele atualizará as unidades de memória [15].

53

5 Segurança de Projeto


Como um projetista de hardware, ou uma casa de projeto, deve proteger sua pro-

priedade intelectual de projeto (IP) contra o uso indevido por usuários, concorrentes, fundição

de silício, etc.? Esse questionamento alerta para alguns passos durante a fase de projeto e co-

mo se obtém segurança como evidência, ultrapassando o apoio da proteção da lei e algumas

técnicas disponíveis para proteger propriedades intelectuais. Essas técnicas incluem marcas

d'água digitais, impressões digitais, medição de circuito integrado e ofuscação de design.

De acordo com Cambridge International Dictionary of English [16], a proprieda-

de intelectual é uma ideia original que pode ser usada para ganhar dinheiro. O original reflete

a novidade da propriedade intelectual e a frase 'pode ser usada' implica na usabilidade da

propriedade intelectual. Exemplos de propriedades intelectuais são produtos, tecnologias,

softwares e assim por diante. Enquanto isso, entende-se que a pessoa ou grupo que é reconhe-

cido como sendo detentor da ideia pode usar a lei para impedir que outras pessoas ganhem

dinheiro copiando-o. Essa aplicação da lei inclui patentes, direitos autorais, segredos comerci-

ais e assim por diante.

Em projetos VLSI [15], uma propriedade intelectual é uma unidade de projeto

que pode ser razoavelmente vista como um subcomponente independente de um projeto com-

pleto de um chip no sistema. Pode ser qualquer inovação tecnológica que torna os projetos

melhores. Por exemplo, um algoritmo de projeto de um ambiente, uma técnica de gerencia-

mento de energia, um projeto novo ou método de teste. Todos esses são considerados IPs de

projeto. Exemplos mais tangíveis incluem microprocessador, chip de memória, microinterface

PISA, netlist totalmente roteada, descrições de chips em Verilog. Esses também são compo-

nentes virtuais, blocos, núcleos, às vezes chamados de macros baseado em seu desempenho e

flexibilidade.

Segundo [15], os projetos de propriedades intelectuais podem ser categorizados

em três grupos. Os IPs rígidos incluem arquivos GDSII com netlist e modelos de alto nível,

layout físico do cliente, totalmente integrado em um netlist roteado para uma dada biblioteca

de tecnologia. Estes IPs rígidos têm desempenho previsível e, na maioria das vezes, otimiza-

do, entretanto são inflexíveis. Os soft IPs são entregues na forma de código HDL sintetizável,

como os códigos Verilog ou VHDL. Estes oferecem grandes flexibilidades de projeto, apesar

54

do desempenho previsível. IPs firmes são colocados em sub-blocos RTL do netlist local,

para a biblioteca de tecnologia genérica. Podem ser considerados como IPs rígidos e soft IPs.

A força impulsionadora por trás das propriedades intelectuais é o projeto produtivo, cuja la-

cuna de produtividade está entre o que pode ser construído e o que pode ser projetado, con-

forme mostra a figura 27.

Figura 27 – Contagem de Transistores [15]

A figura 27 mostra as contagens de transistores da CPU no período de 40 anos,

seguindo a lei de Moore, que diz que o número de transistores em um chip é dobrado a cada

18 meses.

O importante é que, em 1971, surgiu o chip Intel 4004, com o processador com

2300 transistores, de tecnologia de 10 micrômetros, algo que na atualidade avançou para 20

nanômetros e os processadores têm andares, como edifícios, de transistores. A capacidade do

silício aumentou para quase 1 bilhão de vezes no período de 40 anos, mas projetistas com a

capacidade de fazer projetos significativos com tais transistores não aumentou no mesmo rit-

mo e isso criou a lacuna de produtividade do projeto.

5.2 Propriedade Intelectual de Projeto Baseado em Reutilização

Uma das maneiras mais eficazes de fechar a lacuna de produtividade é reutilizar a

base do projeto. Começou a partir de meados dos anos 90, existindo iniciativas no setor sobre

55

a reutilização de IP, como nos Estados Unidos, a Virtual Software Interface Alliance, também

conhecida como VSIA e Virtual Component Exchange.

Dentro da concepção de reutilização na Europa [15], os IPs são desenvolvidos não

apenas para uso, mas também para reutilização, com a qual os engenheiros de projeto são for-

çados a cooperar e compartilhar seus dados e experiências. São documentados e tornados pú-

blicos, para que a reutilização seja mais conveniente. Mas, ao mesmo tempo, esses esforços

fizeram a pirataria de IP e a infração muito mais fácil. Desde o início dos anos 90, os proces-

sos judiciais de semicondutores relacionados à violação de IP aumentaram muito, causando

uma perda de receita anual estimada em bilhões de dólares.

A ameaça mais perigosa para o IP [13] foi a pirataria que veio na forma de enge-

nharia reversa, excedente de chips e falsificação. A engenharia reversa é o processo em que

um produto é desmontado e analisado para melhorar ou duplicar este produto. Para IPs de

projeto de hardware, o custo e os esquemas necessários para engenharia reversa são muito

menores do que aquelas para desenvolver o IP original. Isso dá um incentivo à pirataria de IP.

O excesso de construção de chips refere-se ao cenário, onde a fundição fabrica mais fichas do

que a ordem. Desta maneira, vende as cópias extras para o mercado, aumentando assim os

lucros.

A falsificação é o caso de um produto de baixa qualidade, ou IP fabricado e ven-

dido como uma marca de alta qualidade. A virtual software interface alliance listou os quatro

objetivos a seguir para proteção da propriedade intelectual.

Número um: permite que os provedores de IP protejam seus IPs contra o uso não

autorizado. Número dois: protege todos os tipos de dados de projeto usados para produzir e

fornecer IPs. Número três: detecta o uso de IPs. E, finalmente, o número 4: rastreio de IPs. Na

prática, a maioria dos projetos IPs são garantidos por impedimentos e mecanismos de prote-

ção. Comumente usados por impedimento, inclui patentes, direitos autorais, contratos, marcas

registradas e segredos comerciais. Eles não impedem diretamente a pirataria de IP, mas de-

sencorajam o uso indevido de IPs, porque o atacante pode enfrentar processos e penalidades

severas para recuperar a perda financeira do provedor de IP. No entanto, é tarefa do provedor

de IP identificar e relatar a violação de IP e que denuncie o atacante. Os mecanismos de pro-

teção, por outro lado, usam meios como criptografia, produtos químicos, ofuscação e hardwa-

res dedicados a prevenir e autorizar o acesso ao IP.

As criptografias por padrão podem ser aplicadas para proteger esses IPs. Por e-

xemplo, tanto a Xilinx quanto a Altera oferecem criptografia em suas placas FPGA. Os produ-

tos químicos também podem ser integrados ao chip, uma proteção passiva, principalmente de

56

dispositivos militares. Quando a superfície do chip é arranhada e exposta ao ar, danificará o

silicone exposto, assim impedindo a engenharia reversa. Paralelamente, o método de ofusca-

ção foi proposto em várias fases do projeto, a fim de disfarçar o projeto e tornar para a enge-

nharia reversa algo muito mais difícil. Além disso, organizações da indústria têm trabalhado

no estabelecimento de padrões para reutilização de IP e proteção do IP. Por exemplo, a virtual

socket interface alliance publicou dois padrões de marcação para proteger IPs rígidos e IPs

flexíveis. A aplicação da lei é o único meio de recuperar a receita perdida para a pirataria de

IP. A criptografia e outros mecanismos de proteção tornam a pirataria de IP mais difícil e

mais cara, mas apenas os esquemas de detecção, como marca d'água digital, impressão digital

e medição de circuito integrado, podem permitir que provedores de IPs identifiquem a ocor-

rência de pirataria de IP. Essa identificação será o primeiro passo para a luta legal contra vio-

lação de IP [13][15].

5.3 Marca D’Água

Os projetos de sistemas digitais podem ser comparados a um produto valioso, que

concentra técnica, esforço e experiência em suas formas de realização, desde software, pro-

gramas HDL, até os dados de netlist e máscara a nível de dispositivo representam a proprie-

dade intelectual (IP), devendo ser cuidadosamente protegida. Portanto, as metodologias de

projeto baseadas na reutilização de IP exigem novos mecanismos para proteger os direitos dos

produtores e proprietários de IP.

Portanto em [17], verifica-se que marca d'água pode impedir que invasores copi-

em ou usem ilegalmente IPs, devido à marca d'água digital. Podendo ser amplamente utilizada

para identificação e notação de direitos autorais de multimídia, dados como texto, imagem,

áudio e vídeo, as técnicas tradicionais de marca d'água aproveitam as limitações dos sistemas

visuais e auditivos humanos e incorporam a assinatura aos dados originais como pequenos

erros.

Isso realmente altera os dados multimídia originais e não pode ser aplicado dire-

tamente para a proteção de propriedades intelectuais de projeto de hardware. Isso ocorre por-

que o valor desses IPs depende de suas funcionalidades corretas e de seu desempenho. Obser-

va-se que, para uma determinada especificação do sistema, normalmente, existem muitas ma-

neiras diferentes de implementar o sistema ou desenvolver os IPs.

57

Diante do exposto, se o projetista de IP criar intencionalmente estruturas na im-

plementação do IP para torná-lo único, essa evidência pode ser usada como marca d'água para

provar a autoria do IP.

5.4 Requisitos de Qualidade de uma Marca d’Água

Os requisitos de qualidade de uma marca d'água compreende algumas técnicas

avançadas para projetar marcas d'água digitais. Neste contexto, uma marca da água de quali-

dade tem que preservar a funcionalidade correta da propriedade intelectual.

Por outro lado, o IP com marca d'água não atende aos requisitos de projeto. Se-

gundo [17], a sobrecarga desejada introduzida pela marca d'água deve ser insignificante ou

muito baixa, este é o valor de muitas propriedades intelectuais que não são apenas suas fun-

cionalidades.

Elevada sobrecarga de design, ou degradação do desempenho, reduzirá o valor da

propriedade intelectual. A marca d'água deve fornecer alta credibilidade da autoria ou a pro-

babilidade de coincidência.

A marca d'água incorporada deve ser fácil de ser detectada como a prova da auto-

ria. No entanto, também deve ser resiliente, no sentido de que será difícil ou impossível para

um adversário remover ou modificar a marca d'água do autor. Transparência significa que a

adição de marca d'água e sua detecção devem ser transparentes para ferramentas de projetos

existentes e também para softwares de projeto. Caso contrário, será difícil adotar um esquema

de marca d'água. Idealmente, uma boa marca d'água também pode ser usada para proteger

partes específicas do projeto ou todo ele. Isso é importante no espaço reutilizado e posterior-

mente na prática de projeto, porque os IPs serão integrados e o projetista pode não conseguir

inserir marcas d'água para manter os IPs [17].

Finalmente, uma marca d'água deve fornecer equidade para todos os projetistas ou

todas possíveis assinaturas. Em seguida, deve-se orientar a usar baixa sobrecarga e fácil detec-

tabilidade para demonstrar como esses recursos podem ser alcançados. A sobrecarga de proje-

to e a degradação do desempenho causada pela marca d'água é imprevisível devido à aleatori-

edade das restrições de projetos adicionais com base na marca d'água aleatória. É fato que a

maioria das ferramentas de design contém algoritmos não determinísticos e além disso, que-

rendo controlar a sobrecarga de design, a segurança da marca d'água pode ser comprometida.

Para resolver esse problema, utiliza-se a abordagem de marca d'água de 2 (duas) fases e 0

58

(zero) sobrecarga. Tal abordagem, inicia o design sem nenhuma marca d'água para obter o

melhor desempenho possível e, em seguida, identificam-se os locais onde se podem inserir

marcas d'água sem introduzir degradação do desempenho e, posteriormente, incorpora-se a

marca d'água, para então refazer o design, a fim de obter uma propriedade intelectual com

marca d'água [13].

5.5 Impressão Digital

Foi abordada a importância da marca d'água digital, levantando informações sobre

os três tipos de projetistas de propriedade intelectual de IP, como restrições adicionais de pro-

jeto. A marca d'água de propriedade intelectual atende satisfatoriamente a essas restrições

adicionais e, portanto, tem certas propriedades que podem ser verificadas para provar a auto-

ria de IP.

Sabe-se que a marca d'água digital pode ser usada para provar a autoria do IP, no

entanto, não é possível distinguir usuários diferentes que estão usando o mesmo IP. A im-

pressão digital é um protocolo que pode fazer com que cada cópia do objeto seja único e dis-

tinguível. Primeiro, ambos são identificadores invisíveis que estão incorporados ao design

permanentemente para fins de proteção da propriedade intelectual. A marca d'água permanece

a mesma para todas as cópias do IP, enquanto as impressões digitais devem ser exclusivas

para cada cópia. Em outras palavras, a impressão digital é equivalente a várias cópias de mar-

cas d'água distintas. Quaisquer técnicas de impressão digital devem abordar os dois problemas

fundamentais. Como gerar IPs com diferentes impressões digitais de forma eficaz e como

distribuir as soluções para os usuários.

Assim, é possível elaborar desafios para impressões digitais. Primeiro, diante da

geração IP, os desafios são como criar múltiplos, ou uma grande quantidade de soluções e,

segundo, como manter a alta qualidade dessas soluções para manter o valor desses IPs, além

de como minimizar o tempo e a complexidade para gerar várias soluções.

É idealmente possível mantê-lo perto do tempo e esforço no mesmo nível de fi-

nanciamento de uma única solução. Na segunda fase, de distribuição de IP, também existem

vários desafios.

Exclusividade significa que diferentes usuários devem receber diferentes e distin-

tos IPs impressos, a fim de fornecer alta credibilidade sobre sua identidade e robustez, reque-

rendo muita dificuldade aos invasores para remover ou alterar as impressões digitais.

59

Finalmente, os IPs impressos devem ser muito diferentes uns dos outros. Esta se-

gunda fase é semelhante ao esquema de distribuição de cópias de impressões digitais de dados

multimídia ou outros artefatos.

Existem muitos esquemas já estabelecidos que são usados. Porém, no restante

deste trabalho, vamos nos concentrar na primeira fase, que é a solução de geração de partícu-

las. Destacam-se duas técnicas diferentes de impressão digital. A primeira é chamada de adi-

ção de restrição, onde começa o problema original. Embora se considere um conjunto de res-

trições de impressões digitais combinando estes dois, é possível formar solução aumentada, o

problema é usar o solucionador de problemas para resolver essa solução aumentada para obter

uma solução de semente.

Figura 28 – Fluxograma Solucionador de Sementes [15]

A solução de semente atende às restrições originais do problema, o que significa

que é válido como um IP. Além disso, também atende às restrições de impressão digital, as-

sim é possível projetar essas restrições de impressões digitais de uma maneira que possa gerar

várias soluções a partir desta solução de semente e isso é o que se chama de conjunto de re-

gras para geração de solução, baseado nas restrições de impressões digitais e também nos

problemas a partir de uma solução. Esse conjunto de regras criará várias soluções para o pro-

jetista.

60

Figura 29 – Fluxograma Adição de Sementes [15]

Neste fluxograma, observa-se que o solucionador de problemas será usado apenas

uma vez, o que significa que o tempo de execução para criar várias soluções por adição de

restrição será semelhante ou, em algum sentido, idêntica à complexidade do tempo para en-

contrar esta solução de semente.

A segunda técnica é chamada de abordagem iterativa. Nesta abordagem, partimos

do problema original, que pode ter marca d'água para refletir a assinatura do projetista, encon-

trando uma solução de semente e então gerando cópias de impressões digitais, em seguida,

combinando com o problema original e a solução de semente.

Figura 30 – Abordagem Iterativa [15]

61

Explicando, seria como construir um subproblema, que é uma pequena parte do

problema original e, então, usar o solucionador de problemas para resolver esse pequeno pro-

blema, a fim de encontrar uma solução para ele. Combinando esta subsolução, o subproblema

e a solução de semente para o problema original, pode-se formar uma nova solução para o

problema original. Isso será colocado no pool de soluções com a impressão digital desse com-

prador. Caso sejam necessárias mais cópias das impressões digitais, pode-se repetir este pro-

cesso e, potencialmente, usar esta nova solução como a solução de sementes para repetir este

processo e, a partir desse fluxograma, é possível observar que o solucionador de problemas

será usado muitas vezes.

Mais precisamente, para gerar cada cópia digital, precisa-se usar este solucionador

de problemas. Contudo, resolve-se um subproblema que potencialmente será muito menos

complexo do que o problema original, então, espera-se que o overhead de tempo de execução

não seja tão alto quanto resolver o problema original.

Neste exemplo, considera-se como gráfico menor uma solução.

Figura 31 – Manipulação de Restrições [15]

Usualmente, utiliza-se o problema de coloração do gráfico como exemplo. A

questão é como dar cada nó em um gráfico de cor, que qualquer dos dois nós que estão conec-

tados pela borda vá ficar com cores diferentes? Deve-se minimizar o número de cores. Agora

se deseja encontrar uma solução de impressões digitais que será diferente da solução origi-

nal. Isso é feito conectando esses nós, B e E. Então, em vez de resolver o problema original,

observa-se sua localidade mudando a cor do nó E de amarelo para verde e, em seguida, for-

62

mar uma nova solução. Mais soluções podem adicionar mais restrições a partir da impressão

digital. A qualidade da solução talvez caia e esse problema pode ser resolvido pelo método de

manipulação de restrições.

Figura 32 – Solução de Esquemas Coloridos [15]

O que se observa é que parte do nó pode ser colorido para se obter a solução. Tu-

do depende das cores que o vizinho tem.

Figura 33 – Solução de Nós Coloridos [15]

Mas verificar as cores de seus vizinhos leva tempo e há não há garantia de que

podemos sempre encontrar uma nova solução. Seria muito boa a criação de mais soluções,

mudando a cor de nós específicos sem verificar seus vizinhos ou seus nós adjacentes. Pode-se

conseguir isso pelo método de duplicação de nós.

Portanto, como conclusão, constatou-se que em um simples fluxo de desenvolvi-

mento tradicional de IP, sem qualquer proteção, pode obter um IP com a mais alta qualidade

63

possível, sintetizado por ferramentas de síntese com base na especificação do projeto original.

No entanto, não se pode provar tal autoria, ou se houver pirataria de IP, não se pode rastrear

onde está a origem da pirataria de IP.

A ideia por trás da marca d'água digital é converter a assinatura do autor de IP em

restrições adicionais de projeto e, em seguida, adicioná-lo à especificação de design original

usando as ferramentas de síntese para auto IP que satisfaça a ambos os conjuntos de restri-

ções. Dessa forma, esconde-se a assinatura do autor IP no IP e, em seguida, recupera-se essa

assinatura para provar a autoria. Por outro lado, a impressão digital adiciona a assinatura do

usuário IP em IPs, em IPs também. Isso nos permitirá distinguir quem recebe cada cópia do IP

e nos permite rastrear o uso de IPs. Finalmente, é importante mencionar que, tanto a marca

d'água digital, quanto a impressão digital, são dissuasoras da pirataria de IP. Elas não impe-

dem que invasores utilizem IPs incorretamente. Além disso, a aplicação da lei é a única ma-

neira de recuperar a receita perdida para a pirataria de IP. No entanto, a marca d'água digital e

impressões digitais são fortes evidências para facilitar o cumprimento da lei.

5.6 Medição de Hardware

Segundo [18], as casas de projeto de hoje não podem arcar com a fabricação de

chips, devido ao alto custo, sendo necessário terceirizar essa fabricação para fundições em

outros lugares e esta terceirização força as fundições a terem acesso aos detalhes dos chips e à

possibilidade de overbuilding, sem a autorização da casa de projeto.

A medição de circuitos integrados, ou medição de hardware, é um método eficaz

para se defender contra essa violação de IP. A medição de circuito integrado é um conjunto de

protocolos de segurança que permite que a casa de projetos atinja o controle da pós-fabricação

sobre seus CIs [18].

As técnicas de medição de IC são desenvolvidas para defesa contra ataques de o-

verbuilding de IC e, como mencionado anteriormente, no processo de fabricação de circuitos

integrados, essas casas e fundições desempenham papéis assimétricos e têm que divulgar os

detalhes de seus IPs, pagando o custo para construir a máscara para fabricar seus produtos.

Uma vez que o IP é liberado e a máscara é construída, a casa de projeto não terá nenhum con-

trole sobre estes. Sendo assim, uma fundição desonesta pode utilizar esta informação e as ins-

talações para reproduzir o projeto com custo insignificante. Isso é conhecido como o over-

building de IP. Podem-se usar técnicas de marca d'água digital para proteger um projeto, po-

64

rém, neste caso, a marca d'água protege a autoria de uma propriedade intelectual e, no IC o-

verbuilding, a fundição apenas reproduz mais cópias do IP do que são necessárias e depois

vende as cópias extras para obter lucro. A fundição não tentará reivindicar a autoria do IP.

A impressão digital permite o rastreamento de propriedades intelectuais indicando

o usuário de IP desonesto que distribuía ilegalmente o IP. Quando os CIs sobrecarregados

carregam uma impressão digital, o usuário que possui essa impressão digital também se torna-

rá vítima do overbuilding do IC. Isso porque esse usuário inocente será agora considerado

como a fonte dessas cópias extras. Como circuitos integrados de medição ou a medição de

hardware resolve esse problema?

Um exemplo da vida cotidiana para isto são os medidores de serviços públicos,

como hidrômetro ou medidor de eletricidade.

Os medidores são instalados e mantidos pelos provedores de serviços públicos pa-

ra monitorar os usuários. No entanto, no caso do IC overbuilding, a fundição é o fornecedor

dos CIs e a casa de projeto que irá receber esses CIs será um tipo de usuário. Então, necessita-

se de uma medição reversa onde o usuário deseja monitorar o provedor.

O conceito básico por trás da medição do IC é habilitar uma tag única para cada

cópia do IC e a certeza que a tag está sob o controle da casa de projeto e não da fundição.

Ao longo dos anos, muitos tipos diferentes de tags foram propostos e usados para

medição de hardware. Estes podem ser categorizados com base em vários critérios. Primeiro,

quando a tag só pode ser usada para identificação barata, é chamado de medição passiva. A

tag na medição ativa também pode fazer muitas outras funcionalidades, como ativar o chip,

desabilitá-lo ou controlá-lo [18]. Os métodos de medição ativos podem ser classificados como

controlados internamente ou controlados externamente com base em se o controle é parte do

projeto ou não.

A medição intrínseca não precisa de ajuda de componentes de hardware adicio-

nais ou da modificação do desenho. No entanto, os métodos de medição extrínseca precisam.

Dependendo se a tag interage com a funcionalidade do chip ou não, temos medição não fun-

cional e medição funcional [18].

Finalmente, algumas tags podem ser reproduzidas e outras não; portanto, cha-

mam-se estas últimas de tags não identificáveis. O número de série é talvez uma das primei-

ras formas de marcação de dispositivos.

Um número de série pode ser indentado fisicamente no dispositivo ou armazena-

do permanentemente na memória. A imagem a seguir mostra um trusted platform module, no

armazenamento de um circuito integrado.

65

Figura 34 – Números de Série [17]

O que se vê são alguns números de série. Por exemplo, tags passivas são extrínse-

cas, porque precisam ser fisicamente indentadas no dispositivo. E elas não são funcionais,

porque não têm nada a ver com a funcionalidade do chip e, mais importante, são reproduzí-

veis.

Pode-se usar outra tag ou pedaço de papel para cobrir isso ou podem-se alterar os

números e é por isso que este texto pode ser reproduzido, tornando-os inadequados para não

permitir o excesso de fundição.

A etiqueta ICID foi proposta por volta de 2007, baseada na variação do fabricante

de silício. Devido a essas variações ocorrerem durante o processo de fabricação do chip, ge-

ralmente acredita-se que eles são aleatórios e incontroláveis. Portanto, o ICID é considerado

como uma tag não identificável e pode ser usado para anti-overbuilding. Dependendo se o ID

requer componentes de hardware adicionais ou não, IC Identification, ou ICID, pode ser in-

trínseco ou extrínseco [18].

Esta abordagem de medição de IC ativa usa a máquina de estados finitos internos

para controlar o monitoramento do chip e os flip-flops adicionais o tornam extrínseco.

Na abordagem de medição de IC ativa externa, a casa de design irá adicionar si-

nais de controle e unidades lógicas, como porta ‘ou exclusivo’ para partes não críticas do de-

sign. A menos que todos os sinais de controle recebam os valores apropriados, o chip ou os

ICs fabricados serão bloqueados.

A casa de design fornecerá uma chave externa para desbloquear cada um dos ICs

baseados em algumas primitivas criptográficas assimétricas, por exemplo, a infraestrutura de

chave pública. Neste caso, vemos que este é um esquema de medição ativo, porque envolve a

interação entre a casa de design e cada CI fabricado. É um método externo, porque o sinal

vem do valor externo fornecido pela casa de projeto.

É extrínseco, porque introduzimos sinais de controle adicionais e portas lógicas.

66

6 Metodologia de Projeto


A metodologia de desenvolvimento em um sistema é a forma como o mesmo é

concebido. Tradicionalmente, o desenvolvimento de sistemas é baseado na construção de

componentes elementares como portas lógicas e transistores.

Os grandes desafios no desenvolvimento e gerenciamento de sistemas de grande

complexidade, sobretudo quando envolvem equipes que trabalham separadamente e que,

normalmente, têm habilidades diferentes (por pertencerem a ramos diferentes da engenharia),

motivaram a criação de linguagens que possibilitam a interação entre as engenharias usando

um formato ou uma linguagem comum. Essas linguagens utilizam um alto nível de abstração

e foram definidas como linguagens de descrição de hardware (HDLs), devido ao fato de ser

possível descrever o comportamento dos componentes do sistema de forma natural. As

principais vantagens do uso das HDLs são [19]:

Permite fases mais curtas no desenvolvimento dos projetos;

Provê um monitoramento e uma verificação constante do desempenho e

comportamento do sistema, pois utiliza um mesmo simulador com os mesmos

sinais para todo o sistema;

O sistema é modelado, independente da tecnologia alvo, e pode ser

implementado e sintetizado de diversos modos. O que provê ao modelo a

possibilidade de ser reutilizado em outros projetos, reduzindo assim o custo do

desenvolvimento; e

Promove uma interface comum entre os diferentes grupos envolvidos no

projeto.

Com essas vantagens, a probabilidade de erro no desenvolvimento é

consideravelmente reduzida, bem como o tempo e custo do projeto.

6.2 Domínios de Abstração

Existem nas linguagens de descrição de hardware, três domínios para representar

os níveis de abstração em um projeto [19][15]:

67

Estrutural – Em que o sistema é definido como um conjunto de componentes e

interconexões (quais componentes o sistema tem);

Comportamental – Em que é descrita a funcionalidade do componente (o que o

sistema faz); e

Físico – Em que o tamanho, a tecnologia e a implementação física são

considerados (como o sistema é feito).

Figura 35 – Níveis de Abstração para os Domínios de Desenvolvimento [10]

A figura 35 representa os diferentes níveis de abstração para esses domínios. Nes-

se diagrama, o nível de abstração cresce de acordo com a distância do centro e é representado

para cada domínio.

No domínio comportamental, o nível de abstração mais alto é o da descrição do

algoritmo do componente a ser desenvolvido, ou seja, somente com o conhecimento do com-

portamento ou funcionalidade do componente é possível descrevê-lo. Para os domínios físico

e estrutural, o nível de abstração mais alto permite apenas que o desenvolvedor descreva o

componente como um conjunto de blocos e suas interconexões, sendo assim necessário co-

nhecer precisamente a configuração interna e as características de seus sinais de entrada e

saída de todos os blocos que constituem o sistema.

Nos níveis de abstração mais baixos, o domínio comportamental também se mos-

tra mais simples. Para o nível de abstração de expressões booleanas no domínio comporta-

68

mental. Por exemplo, a descrição de uma função lógica ‘ou exclusiva’ (XOR) faz-se somente

através da expressão booleana S AB , já no domínio estrutural, é necessário especificar as

operações lógicas básicas, previamente implementadas, S AB AB (caso a porta ‘ou ex-

clusivo’ não tenha sido implementada). No domínio físico, a confecção se dá através das liga-

ções entre transistores em uma determinada tecnologia de integração.

6.3 Fluxo de Desenvolvimento do Circuito

Dispositivos mais complexos são desenvolvidos através de componentes

elementares já criados. A essa metodologia, dá-se o nome de Bottom-up, ou seja, descrição de

mais baixa hierarquia para uma hierarquia mais alta.

Com o advento das linguagens de descrição de hardware, pode-se basear a

geração de código através de sua funcionalidade ou comportamento, simulação e posterior

síntese. A esse método, dá-se o nome de metodologia Top-Down, ou seja, a descrição de uma

hierarquia mais alta para outra mais baixa. A figura 36 ilustra a diferença das metodologias

de desenvolvimento bottom-up e top-down [19].

Figura 36 – Metodologia de Desenvolvimento [10]

A metodologia de fluxo de desenvolvimento Top-Down é mais apropriada para o

uso de metodologias de desenvolvimento baseadas em HDLs e seu uso é possível, devido às

ferramentas de CAD, que promovem a simulação e síntese do código gerado.

Para a obtenção do circuito eletrônico, descrito através de uma metodologia

específica, faz-se a síntese da descrição, a qual permite a sua implementação física [20][21].

69

6.4 Controle Digital

6.4.1 Considerações Iniciais

Os conversores de potência são tipicamente controlados por circuitos analógicos,

que são facilmente encontrados no mercado. Esses circuitos fornecem funções básicas para o

controle e têm como principais vantagens o seu baixo custo e a facilidade de uso.

Os circuitos de correção de fator de potência não fogem a essa regra e usualmente

utilizam CIs comerciais para resolver seus problemas de controle [22],[8],[23].

Existem basicamente duas estratégias de controle de um conversor estático. Uma

estratégia é baseada no monitoramento da corrente da carga do conversor e a outra é baseada

no monitoramento da corrente drenada da rede.

Para as duas estratégias de controle, tem-se uma malha de tensão que deve

garantir que o valor médio da tensão na saída do conversor seja mantido constante, e uma

malha de corrente que efetivamente faz com que o conversor compense as harmônicas de

corrente da carga, impondo uma corrente na rede, de acordo com a estratégia de controle

empregada.

6.4.2 Controle Digital utilizando Circuitos Lógicos Combinacionais

O chaveamento do conversor BUCK é definido, através de uma estratégia de

controle, pela amostra dos sinais da malha de corrente e de tensão. Essas amostras devem ser

devidamente digitalizadas, caso seja feita a opção pelo controle digital, que é o caso deste

trabalho.

Ao fazer o controle de estruturas utilizando circuitos digitais, é necessário um

ambiente de teste e simulação que comporte a descrição de toda a estrutura – sistema de

potência e o controle. Por terem naturezas diferentes – analógica e digital –, a utilização de

uma linguagem que possa utilizar circuitos analógicos, digitais e mistos se torna muito

conveniente.

70

6.4.3 Controle Digital com FPGA

Tipicamente, um chip FPGA tem unidades funcionais, tais como os núcleos de

DSP ou processadores embarcados para certas aplicações. Também podem ter grandes blocos

de memória, entrada e saída de alta velocidade, assim como outros tipos de projetos de IPs.

Este trabalho é um fluxo de projeto típico de sistema baseado em FPGA.

A partir de uma determinada especificação, é selecionado o dispositivo FPGA que

será usado para implementar o sistema que utilizará a descrição de hardware, como Verilog

ou VHDL, para especificar o comportamento do sistema baseado em sua especificação.

O FPGA adotado, xilinx spartan 3E-500, contém 500K portas e 10.476 células ló-

gicas equivalentes, o que o torna suficiente para este trabalho. Os dispositivos FPGA da atua-

lidade podem ter bilhões de transistores sob a tecnologia de 10 nanômetros. Para ajudar os

desenvolvedores de sistema FPGA, a maioria dos vendedores FPGA colocam muitos recursos

adicionais em suas placas FPGA, além de apenas células lógicas programáveis.

O fluxo de projeto deste trabalho não tem qualquer envolvimento com fundições

de silício; tal característica pode poupar muito tempo e muito dinheiro. Esta mesma placa

FPGA pode ser reprogramada para diferentes aplicações ou pode ser modificada para sistemas

com especificações diferentes. Estas características fazem o FPGA uma plataforma de projeto

muito popular. Também em comparação com a implementação de software para as mesmas

especificações, sistemas baseados em FPGA são, em geral, muito mais rápidos, tendo um

consumo de potência muito baixa. Isso ocorre porque a implementação de software normal-

mente precisa do apoio de computadores de uso geral. Computadores de uso geral são muito

mais caros do que placas FPGA. Assim, pode-se ir com a implementação de software, o códi-

go C ou código Java, ou qualquer código de alto nível, compilá-lo e, em seguida, executá-lo

em um sistema específico. Portanto, este tipo de aplicação tem um curto tempo de implemen-

tação, é de eficiente depuração, atualização e também tem baixo custo. Oferecerá as seguintes

vantagens:

Baixo consumo de energia; o sistema projetado é específico para este sistema

de criptografia;

Alta taxa de transferência, ou de alta performance;

Velocidade muito mais rápida do que a implementação em software.

A implementação baseada em FPGA, em certo sentido, é um compromisso de im-

plementação de hardware e software. Primeiro, surge a característica de estrutura celular ló-

71

gica programável em placas FPGA. Estas são boas para implementação de operações bit a bit.

Em segundo lugar, as grandes memórias construídas em placas FPGA. A reconfiguração do

FPGA, já mencionado anteriormente, é bom para a reutilização e integração. Este projeto de-

monstrou que FPGA tem vantagens na implementação de alguns blocos de construção de

criptografia, tais como a aritmética, campo finito, o ellip, cryptoprocessors, curva elíptica.

Aqui são listados alguns benefícios específicos de aplicação em FPGAs. Primeiro,

implementação baseada em FPGA oferece flexibilidade de algoritmo de duas maneiras. A

agilidade; sabe-se que muitas partículas de segurança, como SSL e IPSec, são de algoritmo

independente e talvez implementados com múltiplos ou diferentes algoritmos de criptografia e

isso oferece várias vantagens. Por exemplo, se um algoritmo é quebrado, ele está comprome-

tido. Podemos simplesmente excluí-lo e usar outro algoritmo ou outra implementação para

evitar o protocolo de segurança. E, da mesma forma, quando há um novo algoritmo desenvol-

vido para implementar o protocolo seguro, pode-se adicioná-lo ao sistema para um melhor

desempenho. Segundo, o custo baseado em projetos com solução muito específica torna mais

forte a implementação via FPGA, devido a não haver a necessidade de fabricação em larga

escala, facilitando também manutenção nas versões posteriores; e Terceiro, preocupação com

tamanho, área, velocidade, pode diminuir se o FPGA utilizado atender aos requisitos mínimos

de projeto.

6.5 Comparando os Sistemas em FPGA X ASIC

Em FPGA se torna muito produtivo mudar algoritmos durante a operação do apli-

cativo de destino, por exemplo, protocolos seguros [14]. Ele também faz o protocolo de segu-

rança mais adaptável, devido a fazer upload de novas normas, padrões para aplicações especí-

ficas. Isso é muito caro para se fazer em implementações específicas de aplicativos para im-

plementações em ASIC. Em segundo lugar, a implementação FPGA oferece eficiência de

arquitetura. Quando se corrigem os valores para mais variáveis, o sistema torna-se mais espe-

cífico, em vez de propósito geral. E, em geral, o desempenho do sistema com menos variáveis

será melhor e o hardware mais eficiente. Além disso, quando é preciso mudar os valores dos

parâmetros, refaz-se o projeto, otimiza-se e sintetiza-se em uma placa FPGA, mas não se pode

fazer essas coisas em ASIC. Para se ter o mesmo dispositivo FPGA em múltiplos protocolos

de segurança, através de reconfigurações de tempo de execução, é possível desde que esses

protocolos não sejam usados simultaneamente. Dessa forma, não é necessário implementar

72

hardwares separados para cada um dos protocolos de segurança, através do controle dos re-

cursos do sistema [15].

Assim, a comparação com a implementação de software, a implementação FPGA

normalmente será mais rápida, muitas vezes de dez ou centenas de vezes mais rápido. Ela terá

realmente um desempenho muito semelhante aos poderosos processadores de uso geral. No

entanto, é claro que a execução específica ASIC de aceleradores de segurança será mais rápi-

da do que o sistema baseado em FPGA.

E finalmente, talvez uma das mais importantes vantagens da aplicação FPGA, seja

a sua eficiência de custo. Pelo custo, nós frisamos tanto o preço unitário, como também no

tempo de projeto e custo projeto. Portanto, FPGAs são ideais para a construção de primitivas

de segurança de hardware, como já falamos anteriormente, para o tipo de PUFs ou funções

unclonable físicas e PUF baseado em memória, eles podem simplesmente ser implementados

em FPGAs, um verdadeiro gerador de números aleatórios, números verdadeiros, sendo neces-

sário avaliar alguns critérios como fonte de entropia do verdadeiro gerador de números aleató-

rios.

Em FPGA e outros hardwares, devido às variações de fabricação e outras nuances

imprevisíveis e incontroláveis, há muitas fontes que podem ser usadas para gerar aleatorieda-

de, como jitter de fase na rede de clock, atrasando o caminho em segundos, medindo a efici-

ência de custos do verdadeiro gerador de números aleatórios.

A matriz típica inclui a área, de energia, e o tempo necessário para gerar um bit

aleatório. O baixo custo e alta disponibilidade do FPGA o torna como, uma escolha muito boa

com base neste critério. As matrizes de teste de fluxos de bits aleatórios são geradas através

de um gerador de números aleatórios verdadeiros. Estes fluxos de bits devem ser testados

quanto a previsibilidade bem como outras propriedades estatísticas, podendo haver conjuntos

de testes de aleatoriedade disponíveis. Os fluxos de bits aleatórios, também devem ser seguros

contra-ataques e também robusto contra as variações ambientais como visto em abordagens

de hardware baseada em atender a esses requisitos.

Portanto, da mesma forma que a geração aleatória foi selecionada como facilidade

de implementação, é importante que os verdadeiros geradores de números aleatórios baseados

em FPGA sejam factíveis de implementar.

As principais preocupações no desenvolvimento de circuito são a otimização de

recursos, que sempre realizam um trade-off entre consumo de energia e área do circuito,

tornando-se uma alternativa considerável em um uso futuro para um ASIC [24], e também a

abordagem nas vulnerabilidades em FPGAs e projetos de sistemas baseado em FPGA.

73

6.6 Síntese

A síntese é a transformação de uma descrição de alto nível de abstração em outra

com um nível de abstração mais baixo. Dependendo do nível de abstração da descrição do

sistema, dois tipos de sínteses podem ser considerados [19]:

A síntese comportamental, que traduz a descrição do algoritmo em uma lógica

de transferência de registro RTL (Register Transfer Logic); e

E a síntese de RTL, que traduz uma descrição de transferência de registro em

um modelo de níveis lógicos.

A principal diferença entre as descrições em algoritmos e de transferência de

registro é o esquema de sincronismo clock utilizado.

Em uma segunda etapa, chamada de processo de refinamento ou síntese RTL, se

dá a tradução da descrição RTL como um conjunto de interconexões de portas lógicas. Essa

descrição contém informações sobre atrasos de sinais e problemas particulares que podem

aparecer no circuito.

A síntese RTL tem sido disponibilizada há alguns anos e muitos desenvolvedores

de CADs oferecem produtos de síntese para diferentes linguagens, como o VHDL e o

Verilog. Pelo ponto de vista prático, na maioria dos casos, a especificação da descrição é

diretamente redefinida para uma descrição RTL e uma ferramenta de síntese RTL é usada

para gerar o esquemático.

As ferramentas de síntese têm algumas limitações em relação à descrição utilizada

na modelagem do componente, dependendo do nível de abstração que é considerado. Uma

comparação entre diferentes ferramentas de síntese RTL pode ser encontrada em [25]. Na

descrição de um código em HDL é importante observar como a ferramenta de síntese trabalha

para que o circuito final gerado seja o mais otimizado possível.

Os métodos de síntese automática são largamente utilizados na atualidade, no

entanto, têm algumas diferenças em relação à síntese manual [22]:

O desenvolvedor perde o conhecimento da estrutura que está sendo realmente

implementada no circuito;

A qualidade do projeto final pode ser inferior ao esperado, com o resultado de

uma síntese automática; e

74

O método tradicional de desenvolvimento de hardware, através de

esquemáticos, é alterado, implicando assim numa mudança de mentalidade do

desenvolvedor.

Atualmente, há no mercado diversos fabricantes de dispositivos que proporcionam

a síntese de circuitos lógicos digitais através de HDLs. O circuito lógico final é então

implementado em um dispositivo lógico complexo programável, CPLD (Complex

Programmable Logic Device), ou FPGA, que podem conter circuitos dos mais variados

níveis de complexidade [25]. O uso de FPGA diminui, consideravelmente, o tempo de

prototipagem e o custo de projeto [22].

Com o avanço das HDLs, sistemas que englobam tecnologias analógicas e mistas

podem ser descritos de forma comportamental. A possibilidade de síntese desses sistemas tem

sido amplamente estudada e alguns fabricantes já produzem matrizes analógicas

reprogramáveis FPAA (Field Programmable Analog Array [15]) através de HD, sobretudo

através da linguagem Verilog.

No desenvolvimento de sistemas digitais ou mistos, pode-se utilizar, para uma

eficiente e rápida prototipagem, uma FPAA para basear o circuito analógico e, para se basear

no circuito digital, uma FPGA [26], podendo assim modificar facilmente o comportamento e

as características do sistema a ser desenvolvido.

Conforme abordado, a utilização de HDL é uma vantagem para o

desenvolvimento de um projeto. No próximo capítulo, será abordada a linguagem Verilog, a

qual permite uma grande flexibilidade na descrição de circuitos digitais, analógicos e mistos e

será a linguagem utilizada para a descrição de hardware e para a verificação e validação de

hardware utilizando a “linguagem e”, como metodologia apresentada nesse trabalho.

6.7 Simulação

A simulação dos dispositivos é realizada através do desenvolvimento de

testbench, por meio da linguagem de descrição de hardware Verilog, que produz estímulos

específicos nos registros dos circuitos produzindo resultados esperados, apresentando estes

em forma de onda no simulador ISIM.

O Xilinx® ISim é um simulador da linguagem de descrição de hardware (HDL),

que permite executar simulações comportamentais e temporais para VHDL, Verilog e VHDL

e Verilog AMS, para simulação de sistemas mistos, analógico e digital.

75

Os testes mais elaborados são realizados através da criação de um ambiente de

testes, o qual também pode ser chamado de ambiente de verificação funcional ou testes e

validação de dados e como resultados de simulação do conversor estático de potência (CSP),

apresentando estes em forma de onda no simulador SIMVISION [26].

A verificação e validação foi modelada, por meio da "linguagem e", para suportar

os requisitos especiais de verificação funcional, e fornece abstrações que são especificamente

direcionadas para melhores implementações de conceitos de verificação funcional. A e-

language foi criada, apoiada e reforçada por Verisity Inc., de Mountain View, CA. A

linguagem de verificação de hardware "e" é uma linguagem de programação de alto nível,

especificamente arquitetado para projetos de verificação de hardware; é uma poderosa

ferramenta produtiva, não só por suas construções de programação de alto nível e recursos,

mas também por adequação em projetos e modelagem.

6.8 Verificação e Validação dos Dados

Do ponto de vista da verificação e validação funcional, para verificar a

implementação de projeto é necessário verificar o seu comportamento, isto é, portas de

entrada e saída. Se uma propriedade de um dispositivo não pode ser verificada por meio de

suas portas, em seguida, que a propriedade é ou não controlável, ou seja, não pode ser

ativado; ou não está sendo observada. Esta abordagem de validação é chamada de validação

de caixa preta, cuja abordagem de validação foi utilizada [21].

Como estratégia de verificação com abordagem em caixa preta, parte dos IP’s

foram implementados e uma outra parte foi utilizada de terceiros, a fim de verificar o quanto é

importante evidenciar em uma fase de projeto, do ponto de vista da segurança de hardware,

mostrando a necessidade de diferenciação entre os projetistas que projetam dos que fazem

testes de funcionalidade do circuito.

Para a estratégia de verificação e validação dos dados, com abordagem em caixa–

preta, deve-se garantir que o sistema funcione, conforme especificação técnica do IP,

conferindo se os dados checados e analisados realmente funcionam de forma correta,

garantindo de forma segura o funcionamento do projeto.

76

6.8.1 Fluxo de Validação Funcional do Circuito

Toda a atividade de projeto começa a partir da especificação dele. A tarefa de uma

equipe de projeto é criar uma implementação de hardware através de sua interpretação da

especificação do projeto. A especificação é compreendida pelo projetista, que inicia a imple-

mentação através de uma série de etapas, nas quais ferramentas de automação de projeto a-

propriadas são usadas para passar de um nível de abstração para o próximo em cada passo.

Por exemplo, em um fluxo de projeto ASIC inicia-se em nível RT (Register Transfer), a im-

plementação inicial RTL (Register Transfer Language) é criada pela equipe de projeto da

especificação do projeto. A implementação RTL é então sintetizada num nível estrutural de

portas lógicas netlist. Este netlist é então processado através de estágios de projeto físicos, a

fim de preparar a informação final para a máscara que será utilizada na fabricação de semi-

condutores [27][5].

O passo mais trabalhoso e propenso ao erro no fluxo de projeto é a tradução

manual da especificação do projeto para a implementação do projeto inicial. De um modo

geral, outras tarefas de projeto são menos propensas a erros de funcionamento por causa do

alto grau de automação envolvidos na execução das etapas posteriores.

O principal objetivo da validação funcional é verificar que a implementação

inicial do projeto é funcionalmente equivalente à especificação de concepção. Neste caso, este

projeto obteve sucesso com seus objetivos constituindo um arcabouço com base na

metodologia eRM, eReuse Metodology. Este arcabouço corresponde a um conjunto de

componentes de validação de dados, tempo e registros, comparando os resultados obtidos no

projeto do controlador digital versus os resultados obtidos no ambiente de teste[19].

As metodologias de validação, bem como os componentes reutilizáveis, são con-

ceitos abstratos que levam a melhorias de produtividade de validação, enquanto novas lingua-

gens de validação de hardware estão permitindo um novo conceito e o surgimento de novas

tecnologias [21]. O fluxo de projeto típico e suas tarefas de concepção e validação associadas

são mostrados na figura 37.

77

Figura 37 - Fluxo de Projeto ASIC [21]

As principais razões para erros funcionais em um projeto são [21]:

Ambiguidades na especificação do projeto;

Compreensão errada da especificação, mesmo quando a especificação é clara;

Erros de implementação, mesmo quando o objetivo da implementação é claro;

O principal objetivo da validação funcional é verificar se a implementação inicial

do projeto é funcionalmente equivalente à especificação de concepção.

6.8.2 Testes de Caixa Branca e Caixa Preta

Na figura 38, é mostrada a arquitetura de validação para a validação de caixa

preta. Nota-se que, nesta abordagem, é requerido um modelo de referência para verificar que a

resposta gerada por um dispositivo é, de fato, a resposta esperada [21].

78

Figura 38 – Validação de Caixa Preta [21]

As características que proporcionam uma vantagem de implementação no projeto

podem ser o desempenho, porém não são visíveis através das portas dos dispositivos. Por

exemplo, num ambiente de validação de instruções precisas de uma CPU, com um pipeline,

funcionalmente parecem se comportar do mesmo modo que uma CPU sem um pipeline. Para

verificar o correto funcionamento deste pipeline, é necessário examinar o projeto e monitorar

o comportamento do pipeline e verificar se ele está proporcionando melhoria de desempenho

da CPU. Portanto, mesmo que seja possível criar um modelo de referência, é preciso verificar

se há tais comportamentos internos através das portas dos dispositivos, o esforço associado

com a construção de um modelo preciso faria a validação como caixa preta impraticável na

maioria dos casos [21].

Mesmo nos casos em que um recurso específico pode ser verificado através de

portas de dispositivo, a diferença entre o momento em que a falha é ativada e o tempo que a

falha é observada faria qualquer análise de causalidade difícil de controlar. Para melhorar a

busca pelas falhas, há necessidade da implementação de componentes, a fim de monitorar as

propriedades internas, com potencial para se tornarem fontes de mau funcionamento do

dispositivo. Os testes de caixa branca e caixa cinza possuem abordagens de validação

alternativa que superam as limitações de validação de caixa preta. A validação de caixa

branca, figura 39, refere-se a verificar um projeto através da checagem (checkers de

declaração e monitores), sem usar um modelo de referência. A validação de caixa cinza,

figura 40, refere-se a verificar um projeto usando um modelo de referência, mas utilizando

verificadores (afirmações, checkers e monitores) para melhorar a produtividade de validação

[21].

79

Figura 39 – Validação de Caixa Cinza [21]

Figura 40 – Validação de Caixa Branca [21]

Validação caixa branca é normalmente utilizada para módulos menores nos

estágios iniciais de projeto. Esta abordagem de validação é difícil de reutilizar e de gerenciar.

Em outra via, testes de caixa preta são fáceis de reutilizar como projeto de validação

modificando de nível de módulo para nível do sistema. No entanto, o tempo de latência para a

detecção de erros tem potencial para falhas críticas de erro interno de estado e, a necessidade

de construir um modelo de referência detalhado, faz da validação de caixa preta difícil de

utilização na prática. O teste de caixa cinza permite que o engenheiro de validação encontre o

equilíbrio certo entre propriedade de validação do projeto e construção de um modelo de

referência. Portanto, validação de caixa cinza é a abordagem que fornece o maior benefício

em todo o fluxo de validação [4] [18].

6.9 Desafios da Validação

Como dispositivos digitais se tornam mais complexos e os requisitos de tempo de

colocação no mercado se tornam mais curtos, pressão extra é colocada sobre os engenheiros

de validação para completar exponencialmente a validação de projetos em períodos de tempo

mais curtos. Um certo número de desafios devem ser tratados, a fim de lidar com a crescente

complexidade e completar com sucesso um projeto de validação funcional. Estes desafios são:

80

Produtividade;

Eficiência;

Reutilização;

Exaustividade.

A produtividade de validação é definida como a capacidade de lidar com projetos

maiores em um curto tempo. Para engenheiros de projeto, estes ganhos de produtividade têm

sido possível ao passar do nível de projeto de transistor no nível de projeto de portas RT e

metodologias de projeto a nível de sistema [17].

A eficiência da validação é uma medida de intervenção humana necessária para

concluir uma tarefa de validação. Com a crescente complexidade dos dispositivos, é desejável

reduzir a intervenção manual ou manuseio manual para o mínimo possível. A validação

eficiente é aumentada por meio de automação no ambiente de validação e através da

introdução de utilidades da ferramenta de validação que, com uma metodologia de validação

apropriada, conduz a uma redução da intervenção manual.

Validação e Reutilização referem-se à capacidade de reutilizar um ambiente de

validação existente, ou pedaços de um ambiente de validação existentes, para novos projetos

ou gerações posteriores do mesmo projeto. Reutilização é abordada através do

desenvolvimento de uma arquitetura modular para a validação ambiente onde os módulos dos

limites são identificados como peças que são de reutilização-candidatos em novos projetos.

Ganhos adicionais podem ser feitos através de uma melhor documentação da validação de

arquitetura e da utilização de técnicas de programação e manutenção de software disponível

que simplificam a melhoria código [17] [18] [19].

Validação de exaustividade tem o objetivo de cobrir o máximo de funcionalidade

do projeto possível. Melhorar a produtividade de validação, eficiência e usabilidade irá

proporcionar mais tempo para se concentrar em melhorar a integralidade da validação.

Também é possível melhorar ainda mais a integridade através da introdução de metodologias

de validação que incidem sobre esta questão e instalações que dão maior visibilidade ao

progresso validação. Responder claramente a estes desafios de forma eficaz só é possível

através de uma abrangente abordagem. Em suma, estes desafios de validação devem ser

abordados através de:

Novas metodologias de validação;

Movendo-se para níveis mais altos de abstração;

Usando técnicas de projeto modular;

Medir o progresso de validação;

81

Reduzir o esforço manual através da automação;

Melhor ambiente de desenvolvimento de software;

Melhor documentação;

Usando técnicas de desenvolvimento de software;

Novos recursos de linguagem de validação (utilitários) para facilitar estas

novas exigências de desenvolvimento de metodologia e software.

6.9.1 Validação Baseada em Simulação

A operação fundamental na validação em simulação é o processo de ativação do

estado [17] do dispositivo seguido de validação da resposta do dispositivo, figura 41. Nesta

operação, o dispositivo é colocado em um estado em que a resposta correta do dispositivo

específico está marcada em um estado. Nota-se que, nesta representação, um estado do

dispositivo pode se referir a um estado do dispositivo simples, como definido pelo conteúdo

dos seus registros e o estado de suas máquinas de estado. Um estado nesta representação pode

também representar um modo operacional do dispositivo no qual o dispositivo pode passar

por muitos estados simples ao operar em tal modo. Por exemplo, em uma máquina de estados,

o estado do dispositivo neste diagrama pode referir-se a um estado da máquina de estado,

enquanto que, para um módulo de interface de barramento, um estado pode se referir e

escrever ou ler ciclos de operação para o módulo de interface.

Figura 41 – Validação por Simulação [21]

Todos os requisitos funcionais de validação [18] podem ser descritos como uma

série fundamental de operações. A figura 42 mostra uma representação conceitual do espaço

de validação para um dado dispositivo. Esta representação descreve a relação entre os passos

de simulação em termos de estímulo necessário para mover o dispositivo para um dado

estado.

82

Figura 42 – Representação de Casos Validados [21]

O objetivo da validação seria gerar o impulso necessário para colocar o

dispositivo no estado que se deseja atingir [18] [19]. Como o dispositivo se move em novos

estados no seu caminho para o estado desejado, verificadores garantem uma correta resposta

do dispositivo em cada passo. Devido à definição abstrata de um estado do dispositivo em que

cada estado pode também representar um modo de funcionamento do dispositivo, é possível

definir uma validação hierárquica, espaço onde níveis mais elevados, tal como o diagrama

descreve o funcionamento correto do dispositivo, uma vez que se move de um modo de

funcionamento para outro, enquanto, a níveis mais baixos, um diagrama representa

funcionamento correto do dispositivo no nível mais detalhado. Considere uma máquina de

estado e seu espaço de validação correspondente mostrado na figura 43.

Figura 43 - Validação Hierárquica [21]

O espaço de validação de um módulo de interface de barramento, mostrada na

figura 44, apresenta os objetivos da validação em termos de modos de operação para o

módulo de interface de barramento.

83

Figura 44 – Objetivo da Validação Específica [21]

É importante notar que o objetivo da validação muitas vezes não depende apenas

de chegar a um estado específico [17], mas também sobre a forma que o alvo da validação é

atingido.

6.9.2 Terminologia de Validação

Validação é a etapa que verifica a regularidade de um ou mais cenários de

validação [19]. Isso pode acontecer se a simulação executar um caminho no espaço de

validação que abrange vários cenários. As coleções de cenários de validação formam o VP

(Plano de Validação). A ferramenta do plano de validação é a coleção de itens de validação

que verifica todos os cenários em um plano de validação. A implementação de projeto que

está a ser verificada é o DUV (Dispositivo sob Validação). O VE (Ambiente de Validação) é a

coleção de DUV e todas as construções de validação relacionadas. No contexto do

desenvolvimento ambiente de validação, o nível físico refere-se a sinalizar descrições em

nível de bits. Visões físicas são usadas para descrever a DUV no nível do hardware. A lógica

vista do tráfego de dados pode corresponder à representação de estrutura de dados de valores

em nível físico. A visão lógica de uma DUV pode corresponder à sua interface de usuário em

um nível de tarefa. Interface física refere-se às portas que são descritas em nível físico.

6.9.3 Métricas de Validação e Qualidade

As metodologias de validação são adotadas de acordo com o seu benefício. É, por-

tanto, necessário identificar um número de métricas que vai ser usado para medir a eficácia de

uma metodologia de validação [19]. Algumas dessas métricas são medidas quantitativamente,

84

enquanto outras são utilizadas como qualitativas. Os seguintes resultados são considerados ao

medir o valor de uma metodologia de validação:

Granularidade;

Produtividade;

Eficácia;

Exaustividade;

Reutilização do meio ambiente de validação;

Reutilização de dados de simulação.

6.9.3.1 Granularidade

Validação de Granularidade é uma métrica qualitativa utilizada para medir o grau

de detalhe (isto é, granularidade) que deve ser considerado na elaboração de um plano de va-

lidação e, posteriormente, completando o projeto de validação. O objetivo final é permitir aos

engenheiros de validação lidarem com conceitos de mais alto nível de abstração possível. É

importante notar que a validação funcional é, em última análise, o tráfego no nível físico (va-

lores lógicos nos dispositivos sinais) que deve ser verificada. Nesse contexto, a mudança para

um nível maior de abstração é apenas possível, se a manipulação da camada escondida sob

essa abstração recentemente introduzida pode ser automatizada sem perda de qualquer detalhe

no nível físico [17] [18]. As metas, objetivos de abstração da validação, permitem se concen-

trar em maior nível de dados que constroem em vez de valores lógicos como fios e registro do

dispositivo. As mais poderosas construções de linguagem permitem que o engenheiro de vali-

dação passe a implementar a mesma tarefa em menor número de linhas de código e, por con-

seguinte, um tempo mais curto. Como é comumente conhecido no desenvolvimento de soft-

ware , o número de erros em um programa de software é proporcional ao número de linhas de

código. Assim, reduzindo o tamanho código de validação, o potencial de erros na validação

do código é também reduzido [18] [19].

85

6.9.3.2 Produtividade

Validação por produtividade é uma medida da quantidade de esforço manual que

está envolvido num projeto de validação [17]. Este esforço manual consiste em:

Desenvolver o ambiente de validação;

Verificar todos os cenários de validação no plano de validação;

Manter o ambiente de validação;

Migrar o ambiente de validação para o próximo projeto;

Manutenção e migração de um ambiente de validação incluem medidas que de-

vem ser antecipadas durante o desenvolvimento do meio de validação. O foco principal no

desenvolvimento de uma metodologia é aumentar a produtividade, minimizar a quantidade de

esforço manual necessário para desenvolver o ambiente e criar o conjunto de itens que verifi-

ca todos os cenários no plano de validação.

6.9.3.3 Eficácia

Durante simulações, o objetivo é verificar todos os cenários descritos no plano de

validação. Validação da eficácia fornece uma medida para a contribuição de uma simulação

no decorrer de uma tarefa global, a fim de verificar todos os cenários no plano de validação.

Idealmente, todo o tempo gasto na execução, qualquer simulação deve melhorar a cobertura

no plano de validação [18] [19].

6.9.3.4 Exaustão

Validação de exaustão é uma medida da parte da função do dispositivo verificado

durante o curso do projeto de validação. Geralmente, nenhum plano de validação pode com-

pletamente especificar todos os recursos e todos os possíveis casos de canto (casos não cober-

tos). Embora seja relativamente fácil definir uma medida da integridade para um plano de

validação (isto é, medir quantos cenários foram cobertos), é difícil de medir integralidade,

quando se refere a todos os recursos possíveis de um projeto [19].

86

Em um ambiente de validação, onde cada cenário é explicitamente verificado (isto

é, a validação dirigida), o dispositivo de validação de integralidade é quase estendido além do

plano de validação de cenários. No entanto, em uma metodologia de validação, em que cená-

rios de validação são aleatoriamente gerados e resposta do dispositivo é automaticamente

marcada, é altamente provável que muitos cenários, além do plano de validação inicial, tam-

bém sejam verificados.

87

7 Descrição de Projeto de Hardware


Qualquer que seja o projeto, necessita-se de uma boa especificação do circuito,

metodologia, segurança e confiança na equipe que descreve o hardware e bons testes de fun-

cionalidade. Assim, o Verilog é concebido com uma ferramenta de descrição de projeto, sen-

do o idioma de descrição de hardware (HDL) . Uma linguagem de descrição de hardware é

uma linguagem usada para descrever um sistema digital. Isso significa apenas que, usando um

HDL, pode-se descrever qualquer hardware (digital) em qualquer nível.

7.2 Linguagem de Descrição de Hardware Verilog

O Verilog é uma das linguagens HDL disponíveis na indústria para design de

hardware. Ele nos permite projetar um design digital em nível de comportamento, nível de

transferência de registro (RTL), nível de porta e no nível do switch. O Verilog permite que os

projetistas de hardware expressem seus projetos com construções comportamentais, adiando

os detalhes da implementação para um estágio posterior no design final. Como qualquer outra

linguagem de descrição de hardware, permite um design na metodologia Bottom-up ou Top-

down.

Segundo [28], Verilog suporta design em diversos níveis diferentes de abstração.

Sendo três deles muito importantes:

Nível comportamental;

Nível de transferência de registro;

Nível de Portas.

7.3 Introdução

Linguagens de descrição de hardware, como Verilog, possuem semelhança

às linguagens de programação de software, porque incluem maneiras de descrever o tempo de

https://en.wikipedia.org/wiki/Programming_language

https://en.wikipedia.org/wiki/Programming_language

88

propagação e as intensidades do sinal (sensibilidade). Portanto existem dois tipos

de operadores de atribuição, sendo:

Atribuição de bloqueio (=) e

Atribuição sem bloqueio (<=).

A atribuição sem bloqueio permite que os projetistas descrevam uma atualização

de máquina de estado sem precisar declarar e usar variáveis de armazenamento temporá-

rio. Como esses conceitos fazem parte da semântica de linguagem do Verilog, os projetistas

poderiam rapidamente escrever descrições de grandes circuitos de forma relativamente com-

pacta e concisa. Na época da introdução de Verilog (1984), essa lingugem representou uma

tremenda melhoria de produtividade para projetistas de circuitos que já estavam usan-

do software de captura esquemática gráfica e programas de software especialmente escritos

para documentar e simular circuitos eletrônicos.

A linguagem Verilog foi introduzida em 1985 pela gateway design automation,

foi comprada pela empresa cadence design systems, em 1989, que tornou a linguagem de do-

mínio público em maio de 1990 com a formação da OVI (Open Verilog International). Atu-

almente o Verilog é um padrão IEEE, já tendo duas extensões ou modificações: Verilog-95

(padrão IEEE 1364-1995), Verilog 2001 (IEEE 1364-2001) e Verilog 2005 (IEEE 1364-

2005).

A dificuldade de desenvolvimento e gerenciamento de sistemas de grande

complexidade, sobretudo quando envolvem equipes que trabalham separadamente e que,

normalmente, têm habilidades diferentes (por pertencerem a ramos diferentes da engenharia),

motivaram a criação de linguagens que possibilitam a interação entre as engenharias, usando

um formato ou uma linguagem comum. Essas linguagens utilizam um alto nível de abstração

e foram definidas como linguagens de descrição de hardware (HDLs), devido ao fato de ser

possível descrever o comportamento dos componentes do sistema de forma natural. As prin-

cipais vantagens do uso das HDL são [28]:

Permite fases mais curtas no desenvolvimento dos projetos;

Provê um monitoramento e uma verificação constante do desempenho e

comportamento do sistema, pois utiliza um mesmo simulador com os mesmos

sinais para todo o sistema;

O sistema é modelado, independente da tecnologia alvo, e pode ser

implementado e sintetizado de diversos modos, o que provê ao modelo a

https://en.wikipedia.org/wiki/Assignment_operator

https://en.wikipedia.org/wiki/Assignment_operator

https://en.wikipedia.org/wiki/Temporary_storage_variable

https://en.wikipedia.org/wiki/Temporary_storage_variable

https://en.wikipedia.org/wiki/Schematic_capture

https://en.wikipedia.org/wiki/Electronic_circuit_simulation

89

possibilidade de ser reutilizado em outros projetos, reduzindo assim o custo do

desenvolvimento; e

Promove uma interface comum entre os diferentes grupos envolvidos no

projeto.

Com essas vantagens, a probabilidade de erro no desenvolvimento é

consideravelmente reduzida, bem como o tempo e custo do projeto.

7.4 Descrição de Especificação (Propriedade Intelectual)

O conversor estático é utilizado em diversas aplicações do nosso cotidiano, das

quais se destacam uso em foguetes, satélites, tablets, aparelhos celulares, DSP’s e Monitores

de LCD. A Figura 45, mostra como ocorre interação dos dispositivos digitais com outros

periféricos. Sendo assim, o controle digital envia sinais ao conversor ADC e então é iniciada

pelo dispositivo driver que recebe o sinal PWM do dispositivo controle. O Driver faz um

buffer e também um duplicador do sinal PWM, gerando assim sinais de saída para o

dispositivo Switch. O dispositivo Switch faz o chaveamento do sinal de entrada, o qual é

filtrado pelo dispositivo filtro, que realiza a filtragem gerando como saída o sinal (filtrado)

para a carga (circuito eletrônico) e para o dispositivo ADC [23].

O funcionamento do conversor estático de potência oferece a seguinte solução a-

presentada na Figura 45.

Figura 45 – Bloco do Conversor Estático de Potência [1]

Como visto na figura 45, o conversor estático de potência é composto por partes

digitais e partes analógicas, estas simuladas em ferramentas de simulação, sendo o SIMVISI-

90

ON que, devido à ferramenta utilizada fornecer tal simulador, através da construção de test-

bench, substituirá o dispositivo analógico de conversão chamado de conversor ADC.

7.5 Descrição de Entrada e Saída

Portanto, a funcionalidade deste trabalho apresentou como geração de estímulos

os sinais de entrada e saída, conforme figura 46. O bloco representado será descrito em níveis

mais baixos, ou para descrição de nível binário, para pensar em como enxergar essa função no

nível booleano, até para o nível mais baixo, basta verificar a entrada e a saída de quatro bits.

Com essa observação, o projetista adentra-se na fase de projeto, em que esta fase de geração

de entrada e saída representa a funcionalidade do sistema, dessa forma se expressa a saída

como uma função booleana de entrada e, ao fazer qualquer tipo de técnica de otimização, é

possível descobrir a saída z, que neste caso será produzida a saída do PWM, o que significa

que, após correção de controlador, a saída fornecida poderá converter entre 0 a 3.3V. Sendo

assim, abaixo citamos algumas características:

Geração do Clock PWM de 1 MHZ (Mega-Hertz);

ADC de 8 Bits de 100 Kbps;

Converte de 0 V até 3.3 V de saída;

Recepção serial dos dados;

Ajuste do Duty Cycle no PID

O ADC converte o sinal analógico da tensão de saída num sinal digital de 8 bits,

trabalhando conforme a fórmula apresentada em

(15), [29][30],

(15)

onde, conforme a figura 46, algumas das especificações são:

Figura 46 - Conversor ADC [31]

91

O conversor ADC envia o resultado obtido na saída do dispositivo para o soma-

dor, que faz uma comparação de valores entre a entrada serial e o conversor ADC. O resulta-

do dessa operação é enviado ao dispositivo PID que é responsável pelo reajuste dos valores,

para determinar a correção na geração do duty cycle necessário para que a tensão de saída do

conversor estático se mantenha no nível desejado. O PWM é o gerador do duty cycle que de-

termina a tensão de saída para o dispositivo acoplado ao circuito [32].

Tabela 1 – Entradas e Saídas

Nome Ativo Descrição

Clock Borda de subida Clock principal

Reset 0 Reinicializa o sistema

Serial_tx Síncrono Dado serial

Serial_rx Síncrono Dado serial

ADC Barramento de 8 bits

Trigger Ativo alto Conversão realizada

PWM Sinal de Saída “o”

Flag (erro serial) Ativo alto Erro de recepção de dados

7.6 Descrição de Comportamento de Integração

Códigos de integração TOP HDL

Escala de tempo tem o formato de unidade/precisão. Não tem efeito na síntese. É

usado para modelagem de simulação.

Figura 47 – Escala de Tempo

Em Verilog [20], chamamos módulo de"caixas pretas" . Esta é uma palavra reser-

vada dentro do programa usado para se referir a coisas com entradas, saídas e funcionamento

lógico interno; eles são os equivalentes aproximados de funções com retornos em outras lin-

guagens de programação [24].

`timescale 1ns/10ps

92

Figura 48 – Módulo Top Bloco

A linguagem Verilog tem dois tipos de dados principais: Redes, representam

conexões estruturais entre os componentes, e Registros, representam variáveis usadas para

armazenar dados.

Cada sinal tem um tipo de dado associado a ele: Explicitamente declarado

com uma declaração no seu código Verilog.

Implicitamente declarado sem declaração, quando usado para conectar blocos de

construção estruturais em seu código. A declaração implícita é sempre um tipo de rede "wire"

e tem um bit de largura [14][20].

module top_csp ( top_clk_i,

top_reset_i,

top_serial_i,

top_adc_i,

top_enable_i,

top_pwm_o,

top_serial_error_o,

top_flag_ok_o,

top_serial_o

);

//parameter input

parameter bits_1 = 8;



//inputs e outputs

input top_clk_i;

input top_reset_i;

input top_serial_i;

input [bits_1-1:0] top_adc_i;

input top_enable_i;

output top_pwm_o;

output top_serial_error_o;

output top_flag_ok_o;

output top_serial_o;

93

Figura 49 – Fios e Interconexões

As instruções de atribuição de procedimentos atribuem valores a variáveis reg, in-

teiras, reais ou de tempo, e não podem atribuir valores a redes (tipos de dados de conexão),

mas podem atribuir a um registrador (tipo de dado reg) o valor de uma rede (fio), constante,

outro registro ou um valor específico.

Na figura 50 há uma atribuição de valores de entrada e saída.

//wires the interconnection

wire w_clk;

wire w_reset;

wire w_serial;

wire [bits_1-1:0] w_adc;

wire w_enable_adc;

wire w_pwm;

wire w_serial_error;

wire w_serial_out;

wire [bits_1-1:0] w_soft_sum;

wire [bits_1:0] w_somador_pid;

wire [bits_2-1:0] w_pid_pwm;

wire w_enable_somador;

wire [bits_1-1:0] w_serial_soft;

wire w_pulse_enable;

wire w_flag_out;

wire [bits_1-1:0] w_adc_sncy;

wire [bits_3-1:0] w_constant_p;

wire [bits_3-1:0] w_constant_i;

wire [bits_3-1:0] w_constant_d;

wire [00:00] w_clear;

wire [00:00] w_interrupt;

wire [07:00] w_data_dra_uart;

wire [07:00] w_data_uart_dra;

wire w_data_dra_start_tx;

94

Figura 50 – Entradas e Saídas

E a figura abaixo mostra a estrutura que é representada por instâncias do módulo

UART.

Figura 51 – Instâncias do Módulo UART

A figura 52 mostra a estrutura que é representada por instâncias do módulo DRA.

//inputs and outputs assign

assign w_clk = top_clk_i;

assign w_reset = top_reset_i;

assign w_serial = top_serial_i;

assign w_adc = top_adc_i;

assign w_enable_adc = top_enable_i;

assign top_pwm_o = w_pwm;

assign top_serial_error_o = w_serial_error;

assign top_flag_ok_o = w_flag_out;

assign top_serial_o = w_serial_out;

//serial instance

UART DUT_UART (

.CLOCK (w_clk ),

.RESET (w_reset ),

.RX (w_serial ),

.CLEAR_BIT (w_clear ),

.TX (w_serial_out ),

.INTERRUPT (w_interrupt ),

.ERROR (w_serial_error ),

.DATA_IN (w_data_dra_uart ),

.START_TX

(w_data_dra_start_tx),

.DATA_OUT (w_data_uart_dra )

);

95

Figura 52 – Módulo DRA

A figura 53 mostra a estrutura que é representada por instâncias do módulo

PWM.

// direct register access instance

DRA DUT_DRA (

.clock (w_clk ),

.reset (w_reset ),

.interrupt (w_interrupt ),

.data_i (w_data_uart_dra ),

.adc_i (w_adc_sncy ),

.pid_i (w_pid_pwm ),

.clear (w_clear ),

.Vin (w_serial_soft ),

.Kp (w_constant_p ),

.Kd (w_constant_d ),

.Ki (w_constant_i ),

.data_o (w_data_dra_uart ),

.start_tx

(w_data_dra_start_tx)

);

96

Figura 53 – Módulo PWM

A figura 54 mostra a estrutura que é representada por instâncias do módulo PID.

Figura 54 – Módulo PID

A figura 55 mostra a estrutura que é representada por instâncias do módulo Soft

Starter.

//PWM instance

pwm utt_pwm

(.pwm_out(w_pwm),

.pwm_in(w_pid_pwm),

.clk(w_clk),

.clk_2(w_clk),

.reset(w_reset)

);

//PID instance

pid utt_pid (.pid_out(w_pid_pwm),

.clk(w_clk),

.reset(w_reset),

.pid_in(w_somador_pid),

.kp_i(w_constant_p),

.ki_i(w_constant_i),

.kd_i(w_constant_d),

.enable_i(w_enable_somador )

);

97

Figura 55 – Módulo Soft Starter

A figura 56 mostra a estrutura que é representada por instâncias do módulo Ena-

ble Sum.

Figura 56 – Módulo Enable Sum

A figura 57 mostra a estrutura que é representada por instâncias do módulo

edge detect.

//soft_start instance

soft_start utt_soft_start (.clk(w_clk),

.reset(w_reset),

.enable_sum_i(w_enable_somador),

.data_serial_i(w_serial_soft),

.data_adc_i(w_adc_sncy),

// .enable_adc_i

(w_pulse_enable ),

.data_sum_i(w_somador_pid),

.data_serial_o(w_soft_sum)

);

//sum instance

enable_sum utt_enable_sum (.clk(w_clk),

.reset(w_reset),

.sum_o(w_somador_pid),

.input_adc_i(w_adc_sncy),

.input_soft_i(w_soft_sum),

.enable_edge_i

(w_pulse_enable ),

.enable_o(w_enable_somador )

);

98

Figura 57 – Módulo Edge Detect

A figura 58 mostra a estrutura que é representada por instâncias do módulo stabi-

lizer.

Figura 58 – Módulo Stabilizer

//edge_detect instance

edge_detect utt_edge_detect

(.pulse_enable_o(w_pulse_enable ),

.data_adc_o(w_adc_sncy),

.clk(w_clk),

.reset(w_reset),

.enable_i(w_enable_adc),

.data_adc_i(w_adc)

);

//stabilizer signal instance

stabilizer utt_stabilizer (.clk(w_clk),

.reset(w_reset),

.enable_edge_i(w_pulse_enable),



.stabilizer_o(w_flag_out)

);

endmodule

99

7.7 Descrição de Integração

A integração de IP’s é a junção dos circuitos digitais tornando esta ligação um sis-

tema único. Este processo de integrar circuitos digitais não é uma tarefa simples, pelo contrá-

rio é uma tarefa trabalhosa e desafiadora, principalmente quando se utilizam IP’s de terceiros,

pois normalmente não se têm muitas informações funcionais do IP, testes funcionais e, princi-

palmente, se o IP funciona de forma segura.

Para a integração e modelagem em Verilog, é necessário que o projetista tenha in-

formações sobre a linguagem, ferramenta, especificação e funcionalidade do IP, as quais aju-

darão na análise sintática e semântica do compilador da ferramenta CAD, na qual o código

será executado. Essas informações podem ser acerca dos tipos de variáveis que serão utiliza-

dos para se modelar o sistema, operações matemáticas, constantes matemáticas e físicas ou

um pacote de componentes modelados pelo projetista. A esses pacotes dá-se o nome de bi-

blioteca, library [24].

A linguagem Verilog permite que o projetista mantenha, em uma única descrição,

várias bibliotecas, onde cada parte de seu componente esteja em bibliotecas distintas.

O ISim usa bibliotecas de dispositivos de simulação pré-compilados e atualiza es-

sas bibliotecas automaticamente quando as atualizações são instaladas. Os arquivos necessá-

rios para executar uma simulação no ISim são os seguintes:

Arquivos de projeto, incluindo arquivo de estímulo ou teste;

Bibliotecas de usuários;

Diversos arquivos de dados.

Para continuidade no processo de execução da simulação no ISim é necessário in-

cluir um banco de testes baseado em linguagem HDL, sendo um arquivo de estímulo. Caso o

IP seja de terceiros e não tenha o arquivo de teste de funcionalidade, será necessário que o

projetista crie ou edite um banco de testes, podendo ser um dos seguintes:

Criação ou edição de uma bancada de teste HDL em qualquer editor de texto;

Utilização de um modelo para preencher o arquivo corretamente, como os

disponíveis com a ferramenta ISE;

Criação ou edição de uma bancada de teste HDL em qualquer ferramenta

cedida pelo fornecedor.

Conforme o projeto base de funcionamento do conversor estático de potência, i-

lustrado na figura 45, o projeto segue um fluxo que se inicia com o dispositivo controle digi-

100

tal, o qual recebe sinais de conversão do conversor ADC, sendo estes sinais vitais para que o

dispositivo execute os seus subcontroles, fazendo os cálculos de ajustes necessários para o

funcionamento do circuito. Desta forma é gerado um sinal para que o conversor ADC, de a-

cordo com o valor recebido da interface serial, mantenha o sinal mais estável possível através

do dispositivo PID. A figura 59 mostra a integração do controlador digital.

Figura 59 – Integração dos Circuitos [1]

O PWM é configurado por um registro específico que só pode ser gravado quando

o ciclo de trabalho real é concluído. Após o ciclo de trabalho, o valor do registro pode ser

alterado, iniciando um novo ciclo de trabalho e a frequência do PWM é de 1 MHz.

O sistema implementa uma funcionalidade única, ou seja, processamento digital

de cálculo do erro obtido. Seu design é fortemente restrito, com baixo custo, tamanho peque-

no, alto desempenho e baixo consumo de energia.

Ao contrário dos sistemas de uso geral (estações de trabalho, desktops e notebooks

computadores), projetados para maximizar o número de dispositivos vendidos e, assim, proje-

tados para atender a uma variedade de aplicações, os sistemas embarcados têm suas próprias

características comuns.

Restrições de design incluem tamanho, desempenho, potência, custo unitário, cus-

to não recorrente, flexibilidade, time-to-market, time-to-prototype, segurança e assim por di-

ante. O principal desafio para o projeto de sistemas embarcados é implementar um sistema

que atenda à funcionalidade desejada e, ao mesmo tempo, otimize várias métricas de design

de maneira oportuna.

101

Uma das mais bem sucedidas respostas são a reutilização de IP e metodologia de

design baseada em reutilização [15][24].

102

8 Descrição do Ambiente de Validação

8.1 Validação Funcional

Nos últimos anos [21], avanços significativos em tecnologias de circuito integrado

têm proporcionado aos projetistas a capacidade de programar sistemas digitais com complexi-

dade crescente. Esta tendência levou a uma diferença de produtividade entre metodologias de

projeto e tecnologias de implementação e, devido a esta peculiaridade, desenhos produzidos

por metodologias existentes não produzem circuitos em número suficiente para atender aos

rigorosos prazos do mercado competitivo. A constatação de que a validação funcional hoje

consome entre 50% a 70% do ciclo de projeto fica explícita em comunidades de projetos onde

a validação funcional é o centro das atenções, devido à abordagem de que é possível ter um

ganho de produtividade no processo de validar funcionalmente um dispositivo lógico. Sendo

assim, destacam-se a seguir as melhorias de produtividade que são possíveis através da intro-

dução de:

Novas metodologias de validação adequada para a validação dos sistemas

complexos;

Componentes de validação reutilizáveis;

Linguagens de validação de hardware para facilitar os novos paradigmas de

validação.

A Validação tem como objetivo descrever todas as características que devem ser

testadas em um dispositivo, no caso o CSP. Este ambiente de validação foi construído usando

linguagem de validação de hardware, e language [21].

8.2 Arquitetura do Ambiente de Verificação e Validação dos Dados

A linguagem de validação de hardware é uma linguagem de programação de alto

nível especificamente arquitetada para projetos de validação de hardware. As linguagens de

programação são identificadas pelas seguintes propriedades [21]:

Paradigma de programação;

Fluxo de execução;

103

Modelo de dados;

Estrutura do programa.

Logo abaixo (figura 60) iremos ilustrar o ambiente de validação criado para testar

o CSP. Este ambiente foi desenvolvido com e language, assim como os componentes existen-

tes internamente., estes possuem algumas características padrões da metodologia de validação

chamado eRM, que permite automatização e reutilização para projetos similares [21].

Figura 60 – Sistema de Validação (Ambiente de Verificação) [1]

A figura 60 ilustra um ambiente de verificação funcional, internamente contendo

componentes e, suas principais características, sendo as seguintes [21]:

Checker: Analisa as entradas e saídas e verifica se o projeto corresponde às

funcionalidades da especificação;

Monitor: Reúne as entradas e saídas do circuito a ser analisado pelo verifica-

dor;

Gerador de sequência: Cria sequências de dados para ser aplicado ao dispositi-

vo sob teste;

BFM: Converte os dados gerados pelo gerador de sequências em estímulo para

ser aplicado ao dispositivo sob teste;

Sincronizador: Sincroniza os dados para o ambiente.

104

8.3 E-RM (Metodologia de Reutilização e)

A principal hipótese em reutilizar um ambiente de validação ao longo de gerações

de projeto é que as gerações de projeto têm perfis e características semelhantes, embora ligei-

ramente modificadas ou melhoradas [21]. O principal desafio para alcançar este objetivo é

antecipar futuras alterações de estrutura e identificar os módulos e funcionalidades que são

esperados a mudar.

Em geral, para alcançar este objetivo, o arquiteto do ambiente de validação neces-

sita de componentes de validação a nível de sistema (monitores, verificadores, coletores de

cobertura), podendo funcionar independentemente entre os geradores [21][27].

Então, quando toda a fase de projeto e fabricação estiver em uso pelo usuário po-

de-se considerar estar sob controle e confiável. No entanto, com o aumento da complexidade

do design e com a fundição offshore, muitos desses plugs não são confiáveis. Um exemplo

disso é que uma equipe de design pode ser confiável e, presume-se que esta equipe de projeto

exista por anos; mas, no entanto, estão usando modelos que vêm de outras fontes, estão usan-

do propriedades intelectuais de terceiros, podem usar ferramentas para design e essas coisas

podem não ter sido projetadas com fonte confiável.

8.4 Resultado de Simulação

O resultado da simulação refere-se aos dados que são coletados durante a execu-

ção da simulação e reutilização de dados; é geralmente considerado como parte da estratégia

de coleta de cobertura [21].

8.5 Validação Baseada em Testes Direcionados

Os testes direcionados são baseados em uma técnica de força bruta para concluir

um projeto de validação. Nesta abordagem, um item de validação específico é criado para

cada cenário de validação e novas instalações são implementadas, ou uma infraestrutura exis-

tente é reforçada para suportar os requisitos para cada novo cenário de validação. A figura 61

ilustra os testes direcionados.

105

Figura 61 – Testes Direcionados [21]

Os passos fundamentais na validação de testes direcionados são muito simples

[21], sendo os seguintes:

Completar o plano de validação;

Organizar os cenários no plano de validação, de acordo com algumas conside-

rações prioritárias;

Para cada cenário, melhorar o ambiente existente ou construir novas infraestru-

turas para verificar este cenário específico;

Adicionar o item de validação concluída para a suíte de validação e regressão.

8.6 Tarefa Dirigida

A tarefa direcionada é baseada em testes, cuja forma mais fundamental interage

com o dispositivo sob verificação chamado de DUV, usando sinais de nível físico [21]. A

validação da tarefa impulsiona a metodologia e uma variante de teste da metodologia de vali-

dação direcionada com base em lógica de visualizações é usada para melhorar a produtividade

de validação (16). Na validação funcional ajustada tarefa metodologia [15][21]:

Tráfego é definido em um nível mais alto de abstração (quadros, pacotes, ins-

truções, etc.);

Tarefas de validação são definidas em um nível lógico (escrever a porta lida a

partir da porta, assuntos, instrução, etc.);

106

Utilitários de validação são desenvolvidos para suportar estas novas definições

de estrutura de dados e tarefas;

Cenários de validação são criados em um cenário de cada vez, usando a vali-

dação de utilitários disponíveis.

Figura 62 – Tarefa Dirigida [21]

8.7 Validação Baseada em Testes de Restrição

A randomização é uma técnica poderosa que, quando utilizada adequadamente,

pode reduzir o tempo, aumentando a confiabilidade no funcionamento do projeto. Utilizando

o conceito de randomização para automaticamente gerar sequências aleatórias limitadas, exer-

cendo as funções do dispositivo necessário, verifica os cenários no plano de validação. Esta

metodologia leva a imediatos e significativos ganhos de produtividade e integridade validação

[21].

É evidente que cenários são gerados aleatoriamente, o progresso da validação só

pode ser medido com cada novo cenário gerado e, como o progresso de validação não é co-

nhecido antes da simulação, isso está em contraste com a validação baseada em testes dirigi-

dos que, verificando todos os testes dirigidos, garante uma cobertura completa do plano de

validação. Isto significa que o ambiente de validação suporta uma função para geração de

dados necessária para a infraestrutura medir o progresso de validação. Neste estilo de projeto,

o plano de validação consiste simplesmente em percorrer todas as margens possíveis entre

estados.

Gerador:

Gerar estados aleatórios, restringindo o estado ao conjunto válido de estados;

Gerar insumos aleatórios.

Validações:

Verifique se o próximo estado correto é atingido após cada ciclo de clock;

Verifique se a saída correta é produzida, enquanto em cada estado.

107

Cobertura:

Recolhe-se o conjunto de todos os estados alcançados;

Recolhe-se o conjunto de todos os insumos aplicados, enquanto em um deter-

minado estado.

8.8 Ferramenta de Simulação do Ambiente

Para o projeto de verificação e validação, utilizou-se o sistema Specman ™ Elite

™,que oferece benefícios que resultam em [33]:

Reduções no tempo e recursos necessários para verificação e validação dos

dados;

Melhorias na qualidade do produto.

O sistema Specman Elite [33] automatiza processos de verificação, fornecendo

cobertura e análise funcional, elevando o nível de abstração para análise de cobertura

funcional a partir do RTL para o nível de arquitetura/especificação. Isso significa que é

possível:

Capturar facilmente suas especificações de projeto para configurar um

ambiente de verificação;

Criar de forma rápida e eficaz quantos testes forem necessários;

Criar módulos de autoverificação que incluem verificação de protocolos; e

Identificar com precisão quando seu ciclo de verificação estiver concluído.

O sistema specman elite fornece três principais tecnologias de ativação que

melhoram sua produtividade:

Geração de testes orientada por restrições, tornando possível controlar a

geração automática de testes, capturando restrições das especificações da interface

e do plano de teste funcional;

Verificação de dados e temporais, tornando possível criar módulos de

autoverificação que garantam correção dos dados e conformidade temporal. Para

verificação de dados, pode-se usar um modelo de referência ou uma abordagem

baseada em regras;

Análise de cobertura funcional, tornando possível evitar a criação de testes

redundantes que desperdiçam ciclos de simulação, porque se pode medir o

progresso do esforço de verificação contra um plano de teste funcional.

108

A VIP concentra seu esforço em decifrar especificações e modelar com precisão

os protocolos; um enorme esforço de desenvolvimento que requer conhecimento técnico

profundo. Usando Cadence® VIP (Verification IP) na produção, projetos de sistema sobre

chip (SoC) podem ser verificados com maior velocidade, com maior segurança e com menos

esforço.

Figura 63 – Verificação de IP [21]

Compilando arquivos, o primeiro passo para qualquer testbench é certificar-se de

que o seu código e é compilável, para verificar isso, você precisa executar o comando, con-

forme abaixo.

Geração specman -c "csp_top_tb.e"

Vinculando specman elite com simuladores, depois de verificar a sintaxe do códi-

go e, pode continuar a vinculação. Vamos ver a seguinte versão das ligações:

VCS: Vinculação dinâmica com VCS e sn_compile.sh;

NcVerilog: Carregando uma biblioteca compartilhada dinamicamente no

simulador NC;

Modelsim: Compilando o código para ModelSim (carregando uma biblioteca

compartilhada dinamicamente);

109

Interface com ModelSim. Para fazer a interface com o VCS, usamos o script

sn_compile.sh da seguinte maneira, sendo:

sn_compile.sh -sim vcs -vcs_flags "verilog-file-list" e-lista de arquivos.

Ao vincular o VCS e o specman elite sem o código e compilado, o script

sn_compile.sh cria um executável integrado, denominado vcs_specman, que contém o simu-

lador, o specman elite, e o código Verilog do usuário. O specman elite encontra a biblioteca

de adaptadores apropriada com base nas seguintes variáveis de ambiente em system.specman:

SPECMAN_VCS_ADAPTER = "$ SPECMAN_HOME / platform /

libvcs_sn_adapter.ext"

O executável integrado contém o simulador, o specman elite, o código do usuário

Verilog e o código do usuário. O nome padrão do executável é o módulo e de nível superior,

denominado prefixed with "vcs"

Interface com ModelSim, para executar o specman elite com o ModelSim, deve-

se carregar a biblioteca de inicialização do ModelSim specman elite no simulador no tempo de

execução. A biblioteca de inicialização está disponível em:

$ SPECMAN_HOME / platform / libmti_sn_boot.ext

Para carregar libmti_sn_boot.ext no simulador ModelSim:

vsim -c -pli $ SPECMAN_HOME / platform / libmti_sn_boot.ext hdl_file_list

Construção relacionada com a simulação. Podem ser usadas com a linguagem e.

Algumas delas são dadas abaixo:

'Nome do caminho HDL'

force

release

simulator_command ()

stop_run ()

Algumas funcionalidades básicas da interface do simulador Verilog, como a con-

figuração ou amostragem dos valores de alguns objetos Verilog, são ativadas sem qualquer

ação de sua parte. No entanto, alguns recursos, como a condução contínua de sinais Verilog

ou a chamada de tarefas e funções do Verilog, requerem algumas declarações especificadas

pelo usuário - instruções Verilog ou membros da unidade.

A seção a seguir descreve a funcionalidade do circuito em nível de especificação,

tendo como esforço a interpretação desta especificação, gerando hardware através da descri-

ção em Verilog e executando a simulação do circuito, conforme visto nesta seção, executan-

110

do a simulação e fazendo interfaces com outras ferramentas de simulação, inclusive a verifi-

cação funcional de IP com specman elite.

8.9 UART - Interface Serial

A Interface Serial do CSP (Conversor Estático de Potência) utilizará o padrão de

comunicação UART x. Esse recebe 8 bits de dados e 1 bit de paridade par, para a validação do

dado. Em caso de erro, um sinal de nível lógico alto será enviado pela conexão de erro.

A Serial do CSP terá por finalidade receber bit a bit e acumular em um registrador

interno para leitura do DRA (Direct Register Access), sempre que 8 bits completos forem re-

cebidos sem ocorrer erro, um dado é recebido e um sinal de interrupção será enviado para o

dispositivo DRA. Quando o dispositivo DRA receber o dado, ele enviará para a UART um si-

nal clear bit, para que a UART baixe a flag de interrupção e possa ler outro dado.

Figura 64 – Simulação e Resultados para Interface Serial

A UART também será capaz de transmitir informações internas dos dispositivos

ADC, PID, SOMADOR, e PWM, sendo que a leitura deste ocorrerá sob a identificação de

OPCODE que apontará para o valor o qual será lido. Internamente a UART terá uma taxa de

tranferência (Baud Rate) responsável por gerar uma saída de clock na taxa de 9.600 TX e ou-

tra em 153.600 para o RX. Como segurança na aquisição de dados, será realizada uma vota-

ção entre bits coletados durante a recepção, evitando dessa forma um valor inválido ocasiona-

do por uma falha (Glitch) [7] [8].

111

8.10 DRA - Acesso Direto aos Registros

O DRA será responsável por programar o valor de Vin e dos coeficientes do PID,

tornando desta maneira o CSP totalmente reprogramável. O DRA receberá pela UART o OP-

CODE que será decodificado e selecionará o registrador a ser gravado.

Figura 65 – Simulação e Resultados para Acesso Direto aos Registros

Logo após o OPCODE, o DRA receberá os dados, caso sejam referentes aos coe-

ficientes do PID.

Figura 66 – Simulação e Resultados do PID

Ele acumulará 16 bits, que serão recebidos na sequência de 8+8 bits, formando 16

bits que caracterizam os coeficientes, sendo 6 bits para a esquerda do ponto fixo e 10 para a

direita do ponto fixo. Conforme Tabela 2, verifica-se o endereço dos opcodes e suas respecti-

vas definições [7] [8].

112

- Valor de tensão desejada; programa o Soft Starter;

- Coeficiente da integral; programa o Ki dentro PID;

- Coeficiente da derivada; programa o Kd dentro PID;

- Coeficiente da proporcional; programa o Kp dentro PI;

- Envia o valor lido no ADC para a UART;

- Envia o valor lido no PID para a UART.

Tabela 2 - Endereços e Opcodes

Endereço Nome Tipo

10100000 Vin (Escrita)

10100001 Ki (Escrita)

10100010 Kp (Escrita)

10100011 Kd (Escrita)

10100100 ADC (Leitura)

8.11 SS - Soft-Starter

O soft starter é um dispositivo que tem a função de reduzir a diferença entre o

dado oriundo da UART e do ADC. Desta forma, foram criados degraus de voltagem a se-

rem atingidos até alcançar o valor desejado. Sua função é receber o dado serial e o valor

gerado pelo ADC e calcular o valor de saída para o somador.

Figura 67 – Simulação e Resultados do Soft Starter

113

Esse valor é o resultado do valor da serial modificado, de forma a amenizar a dife-

rença entre os valores do ADC e serial. Esse controle de saída é realizado para regular o ganho

de corrente do dispositivo analógico.

Figura 68 – Simulação e Resultados para Soft Starter

O resultado do somador é o sinal de controle para adequação do degrau de subida

e descida do valor serial enviado ao somador. A partir do momento em que o resultado do

somador se torna estável durante 10 ciclos de clock no ADC, é incrementado ou decrementado

um valor de 0.66 V na saída do Soft Starter.


O incremento ou decremento é controlado por um dispositivo estabilizador interno

que emite um sinal de atualização do valor quando o valor do somador se encontrar estável

durante um período de tempo. Essa operação é realizada até atingir a voltagem desejada e

estabilizar o circuito como um todo.

114


Como descrito, a variação de tensão para considerar o circuito estabilizado deve

variar de 0.1 V para mais e 0.1 V para menos, ou seja, o Soft Starter atualiza os valores até

que se atinja um valor próximo ao desejado.


É dito próximo, pois os valores não são exatos, decorrentes dos cálculos da inte-

gral, proporcional e derivada, realizados pelo dispositivo PID [9].

115

Figura 72 – Simulação e Resultados do Soft Starter

8.12 Estabilizador

O estabilizador é um dispositivo que tem a função de analisar os sinais de entrada

e enviar um trigger quando o circuito esteja com a tensão estabilizada.

Figura 73 – Simulação e Resultados para Estabilizador

Ele é um dispositivo pequeno cuja função é a comparação entre voltagem de en-

trada e a voltagem de saída.

Caso o valor seja próximo ou igual ao valor desejado durante determinado período

de tempo, será enviado um sinal ao dispositivo acoplado, avisando que a tensão do circuito

está estabilizada e pronta para o uso.

116


O tempo necessário para envio do trigger para o dispositivo acoplado é de 10 ci-

clos contínuos de ADC que se encontrem dentro das especificações de tensão desejada. Na

função desse dispositivo, a variação de tensão deve estar entre 0.1 V para mais e 0.1 V para

menos, podendo ser adequada se necessário.


O sinal enviado nada mais é que uma flag indicando que o circuito atingiu a ten-

são desejada. Esse flag, quando acionado, deve ficar ativo (active high) até que haja uma de-

sestabilização ou desligamento do sistema. Caso o sistema desestabilize, o flag deve ser bai-

xado (low) indicando que o sistema está inoperante.


117

8.13 Somador

O dispositivo somador tem a função de calcular o erro baseado no dado recebido

do ADC e o dado recebido do dispositivo serial reajustado pelo dispositivo Soft Starter. Em

outras palavras, o somador é encarregado de calcular a diferença entre os valores atuais e os

desejados e, consequentemente, enviar ao PID.

O somador é um dispositivo que calcula o erro a cada conversão do dispositivo

ADC. O erro será calculado com base na diferença do valor de entrada serial modificada, que

está armazenado no dispositivo Soft Starter, e com o resultado do dispositivo ADC.

A diferença somente será computada e enviada do dispositivo PID, quando o sinal

de trigger do dispositivo edge detect tiver sido acionado, que será um sinal de 1 bit de 1 único

pulso de clock. Após o cálculo do somador, é enviado um novo trigger e o erro calculado para

o dispositivo PID e para o dispositivo Soft Starter. Esse sinal será de um 1 bit e de 1 único

pulso de clock.

O resultado desse dispositivo serve para retroalimentar o dispositivo Soft Starter,

informando ao dispositivo quando adequar o novo degrau de voltagem a ser aumentado ou

diminuído em sua saída.

Figura 77 – Simulação e Resultados do Somador

Essa conexão do dispositivo somador com o Soft Starter ocasiona um loop e por

isso foi implementado sequencialmente para reduzir problemas com latch e com a finalidade

de registrar esse dado de saída.

118

8.14 Detector de Borda

Esse dispositivo é responsável por analisar o sinal de trigger do ADC e convertê-

lo para um único pulso de clock digital. O Edge Detector também é responsável pela sincroni-

zação do dado oriundo de um dispositivo analógico ADC para digital. Desta forma se conse-

gue adequar o sinal e o dado desse dispositivo analógico para os dispositivos digitais.

O dispositivo Edge Detector converte o sinal de trigger do ADC. Nesse dispositi-

vo é convertido o sinal de trigger do ADC que está numa frequência de 1 MHz para uma fre-

quência de 64 MHz. Essa conversão é necessária para que os dispositivos digitais que depen-

dam desse trigger executem as suas funções no período correto.

Figura 78 – Simulação e Resultados do Edge Detector

Esse dispositivo converte um trigger de um único pulso de ADC em um trigger de

um único pulso digital. Esse dispositivo também é responsável pela sincronização do dado do

ADC com o circuito digital de controle.

O dado oriundo do ADC será armazenado em um registrador de 8 bits e repassado

aos demais dispositivos digitais juntamente com o acionamento do trigger sincronizado.

8.15 PID - Proporcional Integral Derivator

O dispositivo PID tem a função de calcular o reajuste do duty cycle necessário pa-

ra que a tensão de saída se mantenha no nível desejado [34][30]. As constantes do PID são

119

programadas pelo usuário através da UART e do DRA, como foi mostrado na descrição ante-

rior.


O dispositivo PID contém três registradores de 9 bits, três registradores de 16 bits

e dois de 24 bits, sendo eles:

Dois registradores de 24 bits (14 bits para representar a parte inteira e 10 bits

para representar a parte fracionária) para armazenar o sinal de controle anterior e o

sinal de controle atual;

Três registradores de 16 bits para armazenar as constantes ,

e , os quais receberão os valores a serem programados,

geralmente tendo um valor decimal;

Três registradores de 9 bits para armazenar o erro atual e dois erros anteriores,

os quais trabalham com um cálculo de ponto fixo, sendo 6 bits para representar a

parte inteira e 10 bits para representar a parte fracionária.


120

O registrador de "erro" oriundo do somador é atualizado toda vez que receber um

sinal de trigger desse somador.

Figura 81 – Simulação e Resultados para PID

O valor de saída do PID vai ser atualizado de acordo com

(16):

(16)

onde:

= Sinal de controle novo;

Sinal de controle anterior;

= Erro;

= Amostra atual;

= Acrescentar à constante.

O dispositivo PID envia seis bits para o dispositivo PWM [23]. Esse valor repre-

senta a parte mais significativa do resultado obtido pelo PID e calculado de forma a gerar o

valor referente à frequência do PWM [35][32].

121

8.16 PWM - Pulso com Modulador

A modulação PWM [32] é uma das mais empregadas. Neste tipo de modulação é

realizado o controle de tensão de saída, de forma a mantê-la em um nível desejado. O princí-

pio básico apresenta uma tensão de saída , obtida a partir de um divisor resistivo, compara-

da com um sinal de referência na entrada do amplificador de erro. O sinal obtido na saída do

amplificador de erro , é o resultado da diferença entre a tensão da saída e o valor de refe-

rência. O sinal V, erro, é comparado com um sinal na entrada de um comparador de tensão

PWM, gerando uma forma de onda retangular , que definirá o tempo de condução da chave

( ); a frequência do sinal estabelece o chaveamento do conversor [23].

A solução digital do dispositivo PWM proporciona um balanço entre custo versus

benefício, facilitando a implementação física.

Figura 82 – Simulação e Resultados do PWM

A implementação do dispositivo PWM é considerada ótima, pois com ele pode-se

ter um melhor controle no nível de corrente e tensão, mantendo o mesmo nível de potência

[11].

A estratégia de verificação do núcleo CSP foi razoavelmente sofisticada [30]. O

design foi muito complexo, os testes de verificação foram encarregados de garantir a alta qua-

lidade do dispositivo. Além disso, a verificação e validação requerem uma exigência de reuti-

lização para as gerações futuras. Para o ambiente de verificação projetado foram elaborados

componentes para aplicação, podendo estes serem reutilizados em diferentes interfaces. De-

senvolvendo um wrapper em torno da interface do DUT e, em seguida, fazendo interface com

122

o meio ambiente. Ambiente de verificação que consiste em BFM, gerador de caso de teste,

monitor e verificador [27][36].

Como em qualquer IP comercial ou desenvolvimento SOC com um tempo agres-

sivo, a minimização do risco é fundamental para entrega. Para muitos desenvolvedores co-

merciais, a decisão de adotar um novo paradigma de verificação pode parecer muito arriscada.

O ambiente specman elite foi construído com eVC do host com poucas tarefas Ve-

rilog, permitindo criar um ambiente de host virtual usando mestres, escravos e árbitros de

barramentos.

O specman elite automatizou os principais aspectos da verificação meio ambiente.

Especificamente, ele funciona gerando estímulos no dispositivo, entradas que podem ser to-

talmente aleatórias ou totalmente dirigidas. Desta forma, podemos alcançar casos específicos

no design, sem ter que forçar um estado específico. Podem-se gerar as entradas pré-execução,

on the fly, ou uma combinação de dois [33].

A Linguagem de verificação e, com a metodologia reutilizável e, especificamente,

o eVC é um ambiente de verificação reutilizável desenvolvido internamente. Assim como um

núcleo de design de IP, isso permitiu que o tempo fosse gasto verificando os aspectos únicos

do projeto, em vez do componentes padrão [21].

Um dos principais objetivos do ambiente de verificação foi a capacidade dos en-

genheiros "não especialistas" da specman poderem usar facilmente o ambiente para desenvol-

ver testes, isso através de "tarefas Verilog", que foram construídas em forma de camadas, u-

sando o specman elite macros. De fato, um grande número de verificações Ethernet testes são

sequências de código semelhantes às anteriores [33].

Através de um mecanismo de restrição, era uma questão simples direcionar o trá-

fego para um comprimento de burst. Diferentes quadros e configurações diferentes do nú-

cleo foram testados.

O conjunto de verificação completo no Specman Elite ambience compreendia

mais de 56 casos de teste e randomização do pacote.

Esta é uma pequena quantidade de testes, dada a complexidade do projeto, que

permitiu obter uma cobertura incomparável com um mínimo número de testes e linhas de có-

digo, tornando essa ferramenta essencial na verificação de circuitos integrados digitais e sis-

temas embarcados seguros e estáveis [36].

123

9 Conclusões

Esta dissertação apresenta a metodologia eRM com uma abordagem da segurança

de hardware, com base na especificação e descrição dos circuitos, utilizando a e language

para verificação de hardware, testando o funcionamento de um circuito digital. Esta metodo-

logia permite descrever a verificação, validação e simulação do código do controle digital de

um conversor estático de potência, em Verilog, estimulados por um conjunto de componentes

de testes.

A metodologia apresentada nesta dissertação demonstra que é possível verificar a

funcionalidade de circuitos integrados digitais, como o controle do conversor de potência.

Através da especificação do IP, é possível checar e entregar circuitos integrados confiáveis e

seguros, a fim de garantir a produção de um circuito confiável e bem testado do ponto de vista

funcional.

A utilização da metodologia eRM proporciona o reuso de codificação, possibili-

tando menor tempo de projeto e menor custo na produção de testes, sendo possível descrever

sua arquitetura de testes com base em um plano de verificação e validação de dados, a fim de

atingir o máximo em possibilidades de testes no circuito verificado. Uma vez encontrando

falhas de projeto ou até mesmo simples erros de fios não conectados em fase de integração de

IP’s, comprova-se que o teste não deve ser realizado por quem projetou o circuito, pois é fato

que o projetista realizando o próprio teste funcional passam despercebidas algumas falhas na

escrita do código ou algum vício de projeto.

Uma outra vantagem da metodologia é a possibilidade de comparar modelos escri-

tos por diferentes projetistas e em diferentes linguagens que produzam os mesmos testes base-

ados na especificação do IP, havendo a comparação dos mesmos testes produzidos aleatoria-

mente.

9.1 Conclusão Final

Este trabalho trouxe fortes indicadores de que é necessário um amplo planejamen-

to para elaboração de um projeto de sistemas embarcados, a fim de otimizar custos e reduzir

tempo na execução de implementação na validação funcional. É imprescindível que na etapa

124

inicial do projeto haja informações importantes quanto às ferramentas utilizadas, recursos

disponíveis, material de apoio, metodologia de implementação, a fim de seguir uma direção

para alcançar resultados satisfatórios e comprovados.

No contexto geral, este projeto é um verdadeiro quebra-cabeça, com diversas pe-

ças de montagem e construção. O desenvolvimento arquitetural foi a montagem e a imple-

mentação foi a construção do projeto, utilizando como ferramenta de projeto a linguagem

Verilog, e como metologia de desenvolvimento de dispositvos de validação funcional e lógica

e language, que mostrou ser uma poderosa ferramenta na construção de sistemas e ambientes

de validação funcional, além de ter um recurso notável que é o reuso de código, tendo esta

metodologia papel importante no teste e na segurança funcional de IP’s.

Assim, fica válida a experiência do hardware em garantir a funcionalidade, pro-

porcionando segurança e confiança, pois verificou-se neste projeto que a utilização de IP’s de

terceiros pode ser uma grande armadilha, podendo haver ‘cavalo de troia’, ‘trojan’ e ‘backdo-

ors’. Neste sentido o hardware deve ser visto como um cofre que guarda objetos de valor,

como ouro, diamantes, joias ou qualquer outra coisa. O pensamento neste caso é como prote-

gê-lo. Este trabalho abordou a metodologia eRM como ferramenta de forte relevância para

testar a funcionalidade do hardware, a fim de verificar se ele realmente está funcionando co-

mo deve funcionar, pois pode ser visto como um cofre que precisa ser reforçado constante-

mente e, para isto, são necessários projetistas confiáveis, para que o cofre não seja aberto com

facilidades e, com este ponto de vista, o trabalho aqui apresentado também implementa um

circuito personalizado ou um hardware de propósito específico. Sobre o hardware de propósi-

to específico, sabe-se que este sempre tem melhor desempenho do que a implementação de

propósito geral, principalmente quando se trata da comunicação com software, e isso leva ao

segundo papel do hardware: segurança e confiança.

9.2 Trabalhos Futuros

Considerando que a área de eletrônica de potência não utilizava a descrição de

circuitos com Verilog como uma opção de projeto, acredita-se que uma continuação natural

para este trabalho seria a implementação de um dispositivo de comunicação com maior capa-

cidade de dispositivos escravos e maior capacidade na transferência de dados. O dispositivo

sugerido com essas características seria SPI no lugar do Serial UART. Também poderia utili-

125

zar outra metologia de validação funcional como UVM e toda construção desta arquitetura

poderia ser realizada em SystemC.

Na parte analógica, um trabalho a ser implementado seria a modelagem em ma-

tlab simulink, algo que não foi possível neste projeto, implementação de circuitos integrados

fazendo a integração do dispositivo analógico com o dispositivo digital.

A simulação de estruturas, empregando a descrição com o SIMULINK, é muito

utilizado na área de projeto de circuitos integrados digitais. Inclusive, este ambiente é desen-

volvido com o objetivo de suportar os dispositivos lógicos programáveis (CPLDs e FPGAs) e

até mesmo em ASIC’s.

126

Referências bibliográficas

[1] L. L. Yuzo Iano, “No Title”, V SPS, pp. 1–1, 2014.

[2] F. de C. Velloso, "Informática: Conceitos Básicos", 8th ed. Rio de Janeiro, 2011.

[3] J. M. F. Costa, Elton B, Victor A. Perone, Thayse L. A. Barbosa, Elmar U. K. Melcher,

“Verificação Funcional para Sistemas Digitais utilizando System Verilog,” Natal, 2012.

[4] A. S. M. L.Swarna Jyothi, Harish R, “Reusable Verification Environment for

verification of Ethernet packet in Ethernet IP core, a verification strategy- an

analysis,” IJCSNS Int. J. Comput. Sci. Netw. Secur., vol. 8, n. 11, pp. 226–236, 2008.

[5] M. J. S. Smith, Application-Specific Integrated Circuits. 1997.

[6] F. P. de S. Ivo Barbi, “A Unity Power Factor Buck Pre-Regulator with Feedforward of

the Output Inductor Current,” 1999.

[7] D. Paice, “Power Electronics Converter Harmonic Multipulse Methods for Clean

Power,” 1996.

[8] C.S Silva, “Power Factor Correction with UC3854.”

[9] I. B. F.J.M. Seixas, “A New 18-Pulse AC-DC Converter with Regulated DC Output and

High Power Factor for Three-Phase Applications”, Congr. Bras. Eletrônica Potência,

pp. 582–587, 1999.

[10] M. Santana, “Uma Metodologia de Desenvolvimento do Controle Digital de

Conversores Estáticos Utilizando FPGA,” 2006.

[11] I. B. Denizar Cruz Martins, Conversores CC-CC Básicos Não Isolados, 2nd ed.

Florianópolis: Edição dos Autores, 2000.

[12] C. A. Petry, “Introdução aos Conversores CC-CC,” Instituto de Eletrônica de Potência,

2001.

[13] F. Koushanfar, Hardware Metering: A Survey”, in Introduction to Hardware Security

and Trust. Springer, 2012.

[14] Y. M. Y. Jin, E. Love, Design for Hardware Trust", in Introduction to Hardware

Security and Trust. Springer, 2012.

[15] M. P. G. Qu, Intellectual Property Protection in VLSI Designs: Theory and Practice,

Kluwer Academic Publishers. Kluwer Academic Publishers, 2003.

[16] PAM PETERS, Cambridge International Dictionary of English. 2004.

[17] Ly. G. Qu, Secure Hardware IPs by Digital Watermark”, in Introduction to Hardware

Security and Trust. 2012.

127

[18] Y. Alkabani and F. Koushanfar, Active Hardware Metering for Intellectual Property

Protection and Security. USENIX Security, 2007.

[19] Teresa Riesgo, Yago Torroja and Eduardo de la Torre, “Design methodologies Based

on Hardware Description Languages”, IEEE Trans. Ind. Electron., vol. 46, pp. 3–12,

1999.

[20] Y. G. Kiran Kintali, “Model-Based Projeto with Simulink, HDL Coder, and Xilinx

System Generator for DSP,” pp. 1–15, 2015.

[21] J. J. Sasan Iman, The e Hardware Verification Language, 1st ed. Springer, 2004.

[22] T. R. and J. U. A. de Castro, P. Zumel, O. García, “Concurrent and Simple Digital

Controller of an AC/DC Converter with Power Factor Correction,” IEEE Trans. Ind.

Electron, vol. 46, pp. 3–12, 1999.

[23] D. M. B J Patella, Prodic, “High-Frequency Digital PWM Controller IC for DC-DC

Converter”, IEEE Trans. POWER ELETRONICS, 2003.

[24] Pong P. Chu, FPGA PROTOTYPING BY VHDL EXAMPLES. 2008.

[25] A. kirschbaum M. Glesner, “State-of-the-art in rapid prototyping,” in XI Brazilian

Symposium on Integrated Circuit Design, 1998, pp. 60–65.

[26] C. D. Systems, “SimVision User Guide”, 2009, pp. 1–346.

[27] G.-Y. S. Myoung-Keun You, Young-Jin Oh, “Implementation of Functional

Verification System Using SystemC,” Int. Conf. Circuits Syst. Comput. Commun., vol.

23, n. 781–784, 2008.

[28] Y. T. and E. de la T. Teresa Riesgo, “Design methodologies Based on Hardware

Description Languages”, IEEE Trans. Ind. Electron., vol. 46.

[29] L. F. P. Mello, "Análise e Projeto de Fontes Chaveadas". 1976.

[30] S. T. Jiann-Shiun Yuan, “Mixed-Signal Hardware Security: Attacks and

Countermeasures for ADC,” mpdi, 2017.

[31] S. B. K. V. H. Wang, “Behavioral Synthesis of Field Programmable Analog Array

Circuits,” ACM Trans. Des. Autom. Electron. Syst., vol. 7, No. 4, pp. 564–604, 2002.

[32] S. R. S. Albert M. Wu, Jinwen Xiao, Dejan Markovic, “Digital PWM Control:

Application in Voltage Regulation Modules”, IEEE Power Electron. Spec. Conf., vol.

1, pp. 77–83, 1999.

[33] I. Verisity Design, “Specman EliteTM,” 2002.

[34] O. Aidan, "Hand Book of Piand PID Controller Tuning Rules". Dublin: Imperial

College Press, 2006.

[35] Dirk Lindeke, “Projeto de um Filtro Ativo Paralelo de 1KVA Usando Técnicas de

128

Controle Analógico e Digital,” 2003.

[36] E. U. K. M. Heron A. Monteiro, Nelson C. S. Campos, Jozias P. Oliveira, Antonio

Marcus N. Lima, Alisson V. Brito, “Energy Consumption Measurement of a FPGA

Full-HD Video Processing Platform”, WCAS, pp. 1–2, 2017.

129

Apêndice A

CODIGO fonte feito em HDL VERILOG (CIRCUITO DO CONTROLADOR);

module clock_div

(

input clk_i ,

input reset ,

output reg clk_adc_o

);

reg [5:0] clock_count;

always @(posedge clk_i)

begin

if (!reset)

begin

clock_count <= 6'd0;

clk_adc_o <= 1'b1;

end

else

begin

if(clock_count == 15)

begin

clock_count <= 6'd0;

clk_adc_o <= ~clk_adc_o;

end

else

clock_count <= clock_count + 1'b1;

end

end

endmodule

;_____________________________________________________

130

module DRA (

clock ,

reset ,

interrupt ,

data_i ,

adc_i ,

pid_i ,

clear ,

Vin ,

Kp ,

Kd ,

Ki ,

data_o ,

start_tx

);

input clock ;

input reset ;

input interrupt ;

input [7:0] data_i;

input [7:0] adc_i;

input [5:0] pid_i;

output clear;

output [7:0] Vin;

output [15:0] Kp ;

output [15:0] Kd ;

output [15:0] Ki ;

output [7:0] data_o;

output start_tx;

reg [7:0] Ki_t;

reg [7:0] Kp_t;

reg [7:0] Kd_t;

131

reg flag_kp;

reg flag_ki;

reg flag_kd;

assign clear = (interrupt)?1'b1:1'b0;

assign Vin = (interrupt & data_i == 8'hA0)?data_i:Vin;

assign Ki = (interrupt & flag_ki & data_i == 8'hA1)?{Ki_t,data_i}:Ki;

assign Kp = (interrupt & flag_kp & data_i == 8'hA2)?{Kp_t,data_i}:Kp;

assign Kd = (interrupt & flag_kd & data_i == 8'hA3)?{Kd_t,data_i}:Kd;

assign data_o = (interrupt & data_i == 8'hA4)?adc_i:(interrupt & data_i ==

8'hA5)?{2'b0,pid_i}:8'd0;

assign start_tx = (interrupt & data_i == 8'hA4)?1'b1:(interrupt & data_i == 8'hA5)?1'b1:1'b0;

always @(posedge clock)

begin

if (reset)

begin

flag_ki <= 1'b0;

Ki_t <= 8'd0;

flag_kp <= 1'b0;

Kp_t <= 8'd0;

flag_kd <= 1'b0;

Kd_t <= 8'd0;

end

else

begin

if(interrupt & data_i == 8'hA1)

begin

if(flag_ki == 0)

begin

Ki_t <= data_i;

flag_ki <= 1'b1;

132

end

else

begin

flag_ki <= 1'b0;

end

end

else if(interrupt & data_i == 8'hA2)

begin

if(flag_kp == 0)

begin

Kp_t <= data_i;

flag_kp <= 1'b1;

end

else

begin

flag_kp <= 1'b0;

end

end

else if(interrupt & data_i == 8'hA3)

begin

if(flag_kd == 0)

begin

Kd_t <= data_i;

flag_kd <= 1'b1;

end

else

begin

flag_kd <= 1'b0;

end

end

end

end

endmodule

;_____________________________________________________

133

`timescale 1ns/10ps

module edge_detect ( pulse_enable_o,

data_adc_o,

clk,

reset,

enable_i,

data_adc_i

);

parameter number_bits = 8;//parameter - data input and output

input clk; //system clock

input reset; //system reset

input enable_i; //adc input signal

input [number_bits-1:0] data_adc_i; //input data

output reg pulse_enable_o; //one pulse signal

output reg [number_bits-1:0] data_adc_o; //output data

reg count;//count pulse

reg enable_aux; //signaling flag

reg [number_bits-1:0] data_adc_aux; //data aux

always @(posedge clk)

begin

if (reset)

begin

count <= 1'b0;

pulse_enable_o <= 1'b0;

data_adc_o <= 8'd0;

enable_aux <= 1'b0;

data_adc_aux <= 8'd0;

end

134

else

begin

//count block

if (count == 1'b0)

begin

if (enable_aux)

count <= enable_aux; //enable == 1

end

else

begin

if (!enable_aux)

count <= enable_aux; //enable == 0

end

//adc edge detector

if (enable_aux && !count)

begin

pulse_enable_o <= ~count; //adc flag

data_adc_o <= data_adc_aux; //adc output

end

else

begin

pulse_enable_o <= count; //adc flag

data_adc_o <= data_adc_o; //adc output

end

//synchronized input enable from adc

if (enable_i)

begin

enable_aux <= enable_i;

data_adc_aux <= data_adc_i;

end

else

begin

enable_aux <= enable_i;

data_adc_aux <= data_adc_aux;

135

end

end

end

endmodule

;_____________________________________________________

`timescale 1ns/10ps

module enable_sum ( sum_o,

enable_o,

clk,

reset,

input_soft_i,

input_adc_i ,

enable_edge_i);

parameter number_bits = 8;

//parameter - data input

parameter number_out = 9;

//parameter - data output

input clk;

//system clock

input reset;

//system reset

input [number_bits-1:0] input_soft_i; //serial data input

input [number_bits-1:0] input_adc_i; //adc data input

input enable_edge_i;

//enable_edge_i signal

output reg [number_out-1:0] sum_o; //data output

output reg enable_o;

//signal data ready

reg [number_out-1:0] internal_soft_i;

reg [number_out-1:0] internal_adc_i;

136

always @(*)

begin

internal_soft_i = {1'b1,input_soft_i};

internal_adc_i = {1'b1,input_adc_i};

end

//sum block


begin

if (reset)

begin

sum_o <= 9'd0;

enable_o <= 1'd0;

end

else

begin

if (enable_edge_i) //verify the new data from soft starter and adc

begin

sum_o <= internal_soft_i - internal_adc_i;

enable_o <= 1'b1;

//data signal ready

end

else

enable_o <= 1'b0;

//data signal

end

end

endmodule

;_____________________________________________________

`timescale 1ns/10ps

137

module pid( pid_out,

clk,

reset,

pid_in,

kp_i,

ki_i,

kd_i,

enable_i);

parameter number_in = 9;

parameter number_cons = 16;

parameter number_acum = 24;

parameter number_out = 6;

input clk;

//system clock

input reset;

//system reset

input [number_in-1:0] pid_in; //data

input

input [number_cons-1:0] kp_i;

//proportional constant input

input [number_cons-1:0] ki_i;

//integral constant input

input [number_cons-1:0] kd_i;

//derivative constant input

input enable_i;

//trigger

output reg [number_out-1:0] pid_out; //data

output

reg [number_in-1:0] i_preview;

//antepenultimate error (n-2)

138

reg [number_in-1:0] d_preview;

//penultimate error (n-1)

reg enable_late;

//enable

parameter constant_p = 16'd0; //default

proportional constant

parameter constant_i = 16'd8; //default

integral constant - 000000_0000001000

parameter constant_d = 16'd0; //default

derivative constant

reg [number_acum-1:0] d_acumulador; //derivative error

accumulator

reg [number_acum-1:0] i_acumulador; //integral error

accumulator

reg [number_acum-1:0] p_acumulador; //proportional

error accumulator

reg [number_acum-1:0] error; //result of

the penultimate error

reg [number_acum-1:0] error_out; //result of

the current error

reg [number_cons-1:0] kp;

//proportional constant

reg [number_cons-1:0] ki; //integral

constant

reg [number_cons-1:0] kd;

//derivative constant

//proportional constant block


begin

if (!reset)

begin

139

kp <= 16'd0;

end

else

begin

if (kp_i > 16'd0)

kp <= kp_i;

else

kp <= constant_p;

end

end

//integral constant block


begin

if (reset)

begin

ki <= 16'd0;

end

else

begin

if (ki_i > 16'd0)

ki <= ki_i;

else

ki <= constant_i;

end

end

//derivative constant block


begin

if (reset)

begin

kd <= 16'd0;

end

140

else

begin

if (kd_i > 16'd0)

kd <= kd_i;

else

kd <= constant_d;

end

end

//proportional calculation block


begin

if (!reset)

begin

p_acumulador <= 24'd0;

end

else

begin

if (enable_i)

p_acumulador <= {8'd0,pid_in [number_in-2:0]} * kp;

//proportional calculation

end

end

//integral calculation block


begin

if (reset)

begin

i_acumulador <= 24'd0;

end

else

begin

if (enable_i)

141

i_acumulador <= i_preview [number_in-2:0] * ki; //integral calcula-

tion block

end

end

//derivative calculation block


begin

if (reset)

begin

d_acumulador <= 24'd0;

end

else

begin

if (enable_i)

d_acumulador <= d_preview [number_in-2:0] * kd; //derivative cal-

culation

end

end

//delay enable block


begin

if (reset)

begin

enable_late <= 1'd0;

end

else

begin

if (enable_i)

enable_late <= 1'b1; //delay one clock cycle

else

enable_late <= 1'b0;

end

142

end

//update of the adjustment error


begin

if (reset)

begin

d_preview <= 9'd0;

i_preview <= 9'd0;

end

else

begin

if (enable_late) //update after the

calculation of the adjustment error

begin

d_preview <= i_preview;

i_preview <= pid_in;

end

end

end

//PID block


begin

if (reset)

begin

error_out <= 24'd0;

end

else

begin

if (enable_late)

begin

if (error_out <= 24'd16777215) //16711680

begin

143

if ((pid_in [8] == 1'b1) && (i_preview [8] == 1'b1) &&

(d_preview [8] == 1'b1))

begin

if (error > (p_acumulador + i_acumulador +

d_acumulador))

error_out <= error - p_acumulador -

i_acumulador - d_acumulador; //decrease accumulated error

else

error_out <= 24'd0;

end

else if ((pid_in [8] == 1'b1) && (i_preview [8] == 1'b1) &&

(d_preview [8] == 1'b0))

begin

if ((error + d_acumulador) > (p_acumulador +

i_acumulador))

error_out <= error - p_acumulador -

i_acumulador + d_acumulador; //decrease accumulated error

else

error_out <= 24'd0;

end


(d_preview [8] == 1'b0))

begin

if ((error + i_acumulador + d_acumulador) >

p_acumulador)

error_out <= error - p_acumulador +

i_acumulador + d_acumulador; //decrease accumulated error 6912 16704768

else

error_out <= 24'd0;

end


(d_preview [8] == 1'b1))

begin

144

if ((error + p_acumulador) > (i_acumulador +

d_acumulador))

error_out <= error + p_acumulador -


else

error_out <= 24'd0;

end


(d_preview [8] == 1'b1))

begin

if ((error + p_acumulador + i_acumulador) >

d_acumulador)

error_out <= error + p_acumulador +


else

error_out <= 24'd0;

end


(d_preview [8] == 1'b1))

begin

if ((error + i_acumulador) > (p_acumulador +

d_acumulador))

error_out <= error - p_acumulador +


else

error_out <= 24'd0;

end


(d_preview [8] == 1'b0))

begin

if ((error + p_acumulador + d_acumulador) >

i_acumulador)

error_out <= error + p_acumulador -

i_acumulador + d_acumulador; //decrease accumulated error

145

else

error_out <= 24'd0;

end

else

error_out <= error + p_acumulador + i_acumulador +

d_acumulador; //increase accumulated error

end

else

error_out <= 24'd16777215;

end

end

end

//data output block


begin

if (reset)

begin

pid_out <= 6'd0;

error <= 24'd0;

end

else

begin

if (enable_late)

error <= {15'd0,d_preview}; //garbage

else

begin

if (error_out <= 24'd16777214) //16711680

begin

pid_out <= error_out [number_acum-1:18];

//PWM output

error <= error_out;

//error (n-1)

end

146

else

begin

pid_out <= 6'd63;

error <= 24'd16777214;

//error (n-1)

end

end

end

end

endmodule

;_____________________________________________________

`timescale 1ns/10ps

module pwm( pwm_out,

pwm_in,

clk,

clk_2,

reset );

parameter number_bits = 5; //parameter input

input clk;

//system clock

input clk_2; //system

clock 2

input reset; //system

reset

input [number_bits-1:0] pwm_in; //data input from PID

output reg pwm_out; //duty

cycle - 1 Mhz

reg [number_bits-1:0] count; //duty cycle count

reg [number_bits-1:0] count_2; //duty cycle count 2

147

reg [number_bits-1:0] duty_register; //duty cycle register

reg [number_bits-1:0] count_baud; //baud rate

wire [number_bits:0] count_aux;

//execution counter of duty cycle


begin

if (reset)

begin

count <= 5'd0; //initial value - count

count_baud <= 5'd31; //initial value - baud

end

else

begin

if (count < count_baud)

count <= count + 1'b1; //total PWM period

else

count <= 5'd0;

end

end

//execution counter of duty cycle

always @(negedge clk_2)

begin

if (reset)

begin

count_2 <= 5'd0; //initial value -

count

end

else

begin

if (count_2 < 5'd31)

count_2 <= count + 1'b1; //total PWM period

148

else

count_2 <= 5'd0;

end

end

assign count_aux = ((count == 5'd31) && (count_2 == 5'd0)) ? 6'd63 : count + count_2;

//duty cycle control

always @(*)

begin

if ((count_aux < duty_register ) || (duty_register == 6'd63))

pwm_out = 1'd1; //output value of PWM

else

pwm_out = 1'd0;

end

//serial data receiver


begin

if (reset)

begin

duty_register <= 5'd0; //initial value - duty register

end

else

begin

if (count_aux >= 6'd61) //duty register - change

at the end cycle

duty_register <= pwm_in;

end

end

// assign duty_register = (count_aux == 6'd63) ? pwm_in : ( (duty_register == pwm_in)

? pwm_in : ( (count_aux < duty_register) ? pwm_in: 0 ) );

149

endmodule

;_____________________________________________________

`timescale 1ns/10ps

module soft_start ( clk,

reset,

enable_sum_i,

data_serial_i,

data_adc_i,

data_sum_i,

data_serial_o);

parameter data_bits = 8;

//parameter - data

parameter signal_stable = 3'd7;

//parameter - estimated value --> ~0.1V

parameter data_jump = 8'd51;

//parameter - step value - 0.66V (degree)

input clk;

//system clock

input reset;

//system reset

input enable_sum_i;

//enable from enable_sum - ready data

input [data_bits-1:0] data_serial_i; //data input from

soft_start

input [data_bits-1:0] data_adc_i; //data

input from edge_detect

input [data_bits:0] data_sum_i;

//data input from enable_sum

output reg [data_bits-1:0] data_serial_o; //output data

150

reg [3:0] count;

//counter

reg stable;

//stable register

reg new_stable;

//stable register - one cycle after stable signal

reg [data_bits-1:0] aux;

//aux register

reg count_stable;

//count stable register

//serial data - modify


begin

if (reset)

aux <= 8'd0;

else

begin

if (data_adc_i == 8'd0)

begin

if ((data_serial_i >= data_jump))

aux <= data_jump;

else

aux <= data_serial_i;

end

else

begin

if(stable)

begin

if(data_adc_i < data_serial_i) //increase

begin

if (((data_serial_i - aux) >= da-

ta_jump) && (aux < data_serial_i)) //if result data is equal or more than 0.66V

151

aux <= aux + data_jump;

//0.66 V

else


end

else //decrease

begin

if ( ((aux - data_serial_i) >=

data_jump) && (aux > data_serial_i) ) //if result data is equal or more than 0.66V

aux <= aux - da-

ta_jump;//-0.66 V

else


end

end

end

end

end

//serial output block


begin

if (reset)

begin

data_serial_o <= 8'd0;

end

else

begin

if (data_adc_i == 8'd0) //initial value after reset

begin

if ((data_serial_i >= data_jump)) //if serial data is equal or more

than 0.66V

begin

data_serial_o <= data_jump;

152

end

else

begin

data_serial_o <= data_serial_i; //data input value

end

end

else if (new_stable)

data_serial_o <= aux;

end

end

//count stable signal


begin

if (reset)

begin

count <= 4'd0;

end

else

begin

if ((enable_sum_i) && (!data_sum_i[8]) && (data_sum_i[7:0] <= sig-

nal_stable) && (!stable) && (data_serial_i != 8'd0))

count <= count + 1'b1;

else if (count == 4'd10)

count <= 4'd0;

end

end

//final stable block


begin

if (reset)

begin

count_stable <= 1'b0;

153

end

else

begin

if (data_serial_i == data_serial_o)


else


end

end

//stable signal


begin

if (reset)

begin

new_stable <= 1'b0;

stable <= 1'b0;

end

else

begin

if ((count == 4'd10) && (!count_stable))

begin

stable <= 1'b1; //stable de signal after 10 cycles

//one clock delay

new_stable <= stable;

end

else

begin

stable <= 1'b0; //only destabilize the signal

//one clock delay

new_stable <= stable;

end

end

end

154

endmodule

;_____________________________________________________

`timescale 1ns/10ps

module stabilizer ( clk,

reset,

enable_edge_i,

data_serial_i,

data_adc_i,

stabilizer_o);

parameter data_bits = 8;

//parameter - data input

parameter count_bit = 4;

//parameter - counter

parameter signal_stable = 3'd7;

//parameter - estimated value --> ~0.1V

input clk;

//system clock

input reset;

//system reset

input enable_edge_i;

//enable from ADC - ready data

input [data_bits-1:0] data_serial_i; //data input from UART

input [data_bits-1:0] data_adc_i; //data

input from ADC

output reg stabilizer_o;

//output stable signal

reg [count_bit-1:0] count;

//count stable signal


155

begin

if (reset)

begin

count <= 4'd0;

//stable signal

stabilizer_o <= 1'b0;

end

else

begin

if (enable_edge_i)

begin

if ((data_serial_i >= data_adc_i) && (data_serial_i != 8'd0) &&

(!stabilizer_o) && ((data_serial_i - data_adc_i) <= signal_stable))

count <= count + 1'b1;

else if ((data_serial_i >= data_adc_i) && (stabilizer_o) && ((da-

ta_serial_i - data_adc_i) > signal_stable))

count <= 4'd0;

end

if (count == 4'd10)

stabilizer_o <= 1'b1; //stable de signal after 10 cycles

else

stabilizer_o <= 1'b0;

end

end

endmodule

;_____________________________________________________

`timescale 1ns/10ps

module top_csp ( top_clk_i,

top_reset_i,

top_serial_i,

top_adc_i,

top_enable_i,

156

top_pwm_o,

top_serial_error_o,

top_flag_ok_o,

top_serial_o

);

//parameter input




//inputs e outputs

input top_clk_i;

input top_reset_i;

input top_serial_i;

input [bits_1-1:0] top_adc_i;

input top_enable_i;

output top_pwm_o;

output top_serial_error_o;

output top_flag_ok_o;

output top_serial_o;

//wires the interconnection

wire w_clk;

wire w_reset;

wire w_serial;

wire [bits_1-1:0] w_adc;

wire w_enable_adc;

wire w_pwm;

wire w_serial_error;

wire w_serial_out;

wire [bits_1-1:0] w_soft_sum;

wire [bits_1:0] w_somador_pid;

wire [bits_2-1:0] w_pid_pwm;

157

wire w_enable_somador;

wire [bits_1-1:0] w_serial_soft;

wire w_pulse_enable;

wire w_flag_out;

wire [bits_1-1:0] w_adc_sncy;

wire [bits_3-1:0] w_constant_p;

wire [bits_3-1:0] w_constant_i;

wire [bits_3-1:0] w_constant_d;

wire [00:00] w_clear;

wire [00:00] w_interrupt;

wire [07:00] w_data_dra_uart;

wire [07:00] w_data_uart_dra;

wire w_data_dra_start_tx;

//inputs and outputs assign

assign w_clk = top_clk_i;

assign w_reset = top_reset_i;

assign w_serial = top_serial_i;

assign w_adc = top_adc_i;

assign w_enable_adc = top_enable_i;

assign top_pwm_o = w_pwm;

assign top_serial_error_o = w_serial_error;

assign top_flag_ok_o = w_flag_out;

assign top_serial_o = w_serial_out;

//serial instance

UART DUT_UART (

.CLOCK (w_clk ),

.RESET (w_reset ),

.RX (w_serial ),

.CLEAR_BIT (w_clear ),

.TX (w_serial_out ),

158

.INTERRUPT (w_interrupt ),

.ERROR (w_serial_error ),

.DATA_IN (w_data_dra_uart ),

.START_TX (w_data_dra_start_tx),

.DATA_OUT (w_data_uart_dra )

);

// direct register access instance

DRA DUT_DRA (

.clock (w_clk ),

.reset (w_reset ),

.interrupt (w_interrupt ),

.data_i (w_data_uart_dra ),

.adc_i (w_adc_sncy ),

.pid_i (w_pid_pwm ),

.clear (w_clear ),

.Vin (w_serial_soft ),

.Kp (w_constant_p ),

.Kd (w_constant_d ),

.Ki (w_constant_i ),

.data_o (w_data_dra_uart ),

.start_tx (w_data_dra_start_tx)

);

//PWM instance

pwm utt_pwm (.pwm_out(w_pwm),

.pwm_in(w_pid_pwm),

.clk(w_clk),

.clk_2(w_clk),

.reset(w_reset)

);

//PID instance

pid utt_pid (.pid_out(w_pid_pwm),

159

.clk(w_clk),

.reset(w_reset),

.pid_in(w_somador_pid),

.kp_i(w_constant_p),

.ki_i(w_constant_i),

.kd_i(w_constant_d),

.enable_i(w_enable_somador )

);

//soft_start instance

soft_start utt_soft_start (.clk(w_clk),

.reset(w_reset),

.enable_sum_i(w_enable_somador),



// .enable_adc_i (w_pulse_enable ),

.data_sum_i(w_somador_pid),

.data_serial_o(w_soft_sum)

);

//sum instance

enable_sum utt_enable_sum (.clk(w_clk),

.reset(w_reset),

.sum_o(w_somador_pid),

.input_adc_i(w_adc_sncy),

.input_soft_i(w_soft_sum),

.enable_edge_i (w_pulse_enable ),

.enable_o(w_enable_somador )

);

//edge_detect instance

edge_detect utt_edge_detect (.pulse_enable_o(w_pulse_enable ),

.data_adc_o(w_adc_sncy),

160

.clk(w_clk),

.reset(w_reset),

.enable_i(w_enable_adc),

.data_adc_i(w_adc)

);

//stabilizer signal instance

stabilizer utt_stabilizer (.clk(w_clk),

.reset(w_reset),

.enable_edge_i(w_pulse_enable),



.stabilizer_o(w_flag_out)

);

endmodule

;_____________________________________________________

`timescale 1ns/1ns

module UART (

input CLOCK,

input RESET,

input RX,

input CLEAR_BIT,

input [7:0] DATA_IN,

input START_TX,

output TX,

output INTERRUPT,

output reg ERROR,

output [7:0] DATA_OUT

);

//wire [7:0] last_data;

//assign last_data = (DATA_IN!=last_data)?DATA_IN:last_data;

161

uart_rx RX0 (

.PCLK(CLOCK),

.RESET(RESET),

.RX_I(RX),

.DATA_RX_O(DATA_OUT),

.WORK_FR(16'd651),

.READY(INTERRUPT),

.PARITY_RX(PARITY_RX)

);

uart_tx TX0 (

.PCLK(CLOCK),

.RESET(RESET),

.START(START_TX),

.WORK_FR(16'd10416),

.DATA_TX_I(DATA_IN),

.READY_TX(READY_TX),

.TX_O(TX)

);

always@(*)

begin

ERROR = 1'b0;

if(INTERRUPT)

begin

if( ^DATA_OUT != PARITY_RX)

begin

ERROR = 1'b1;

end

end

162

end

endmodule

/*

parameter [02:00] WAIT_BIT = 3'd0;

parameter [02:00] START_BIT = 3'd1;

parameter [02:00] READ_BIT = 3'd2;

parameter [02:00] PARITY_BIT = 3'd3;

parameter [02:00] STOP_BIT = 3'd4;

parameter [02:00] RECV_NEW_DATA = 3'd0;

parameter [02:00] TRANSMIT_BIT = 3'd1;

reg [12:00] COUNT;

reg [12:00] COUNT_TX;

reg [03:00] TX_BAUD;

reg [02:00] STATE_RX;

reg [02:00] STATE_TX;

//adicionado estado next_state

reg [2:0] NEXT_STATE_RX;

reg [2:0] NEXT_STATE_TX;

reg [07:00] DATA_RX;

reg [07:00] P_DATA;

//retirar os zeros [00:00] em todos@

reg [00:00] flag_count;

reg [00:00] bit0;

reg [00:00] bit1;

163

reg [00:00] bit2;

reg [03:00] count_data;

//contador

always @(posedge CLOCK)

begin

if (!RESET)

COUNT <= 13'd0;

else

begin

if (flag_count)

begin

if (COUNT < 13'd3333)

COUNT <= COUNT + 1;

else

COUNT <= 13'd0;

end

else

COUNT <= 13'd0;

end

end

// PARTE SEQUENCIAL RX


begin

if (!RESET)

begin

DATA_OUT <= 8'd0 ;

STATE_RX <= WAIT_BIT ;

ERROR <= 1'b0;

flag_count <= 1'b0 ;

bit0 <= 1'b0 ;

bit1 <= 1'b0 ;

164

bit2 <= 1'b0 ;

DATA_RX <= 8'd0 ;

count_data <= 4'd0 ;

INTERRUPT <= 1'b0 ;

end

else

begin

STATE_RX<=NEXT_STATE_RX;

case(STATE_RX)

WAIT_BIT : begin

if (!RX)

begin

flag_count <= 1'b1;

end

if (CLEAR_BIT)

begin

INTERRUPT <= 1'b0;

end

end

START_BIT : begin

if (COUNT == 13'd666)

bit0 <= RX;

if (COUNT == 13'd1332)

bit1 <= RX;

if (COUNT == 13'd1998)

bit2 <= RX;

if (COUNT == 13'd3333)

if (( (bit1 & bit0) | (bit2 & bit1) | (bit2 & bit0) ) == 1'b1 )

begin

flag_count <= 1'b0;

ERROR <= 1'b1;

end

end

READ_BIT : begin

165

ERROR <= 1'b0;

if (COUNT == 13'd2)

if (count_data == 4'd8)

begin

count_data <= 4'd0;

end

else

count_data <= count_data + 1;

if (COUNT == 13'd666)

bit0 <= RX;

else

if (COUNT == 13'd1332)

bit1 <= RX;

else

if (COUNT == 13'd1998)

bit2 <= RX;

else

if (COUNT == 13'd3330)

DATA_RX <= DATA_RX >> 1;

else

if (COUNT == 13'd3333)

if (( (bit1 & bit0) | (bit2 & bit1) | (bit2 & bit0) ) == 1 )

begin

DATA_RX[7] <= 1'b1;

end

else

DATA_RX[7] <= 1'b0;

end

PARITY_BIT : begin

if (COUNT == 13'd666)

begin

bit0 <= RX;

end

166

if (COUNT == 13'd1332)

begin

bit1 <= RX;

end

if (COUNT == 13'd1998)

begin

bit2 <= RX;

end

if (COUNT == 13'd3333)

begin


begin

if ((^DATA_RX) != 1)

begin

ERROR <= 1'b1;

flag_count <= 1'b0;

end

end

else

begin

if ((^DATA_RX) != 0)

begin

ERROR <= 1'b1;

flag_count <= 1'b0;

end

end

end

end

STOP_BIT : begin

if (COUNT == 13'd666)

bit0 <= RX;

if (COUNT == 13'd1332)

bit1 <= RX;

if (COUNT == 13'd1998)

167

bit2 <= RX;

if (COUNT == 13'd3333)


begin

DATA_OUT <= DATA_RX;

INTERRUPT <= 1'b1;

flag_count <= 1'b0;

end

else

begin

ERROR <= 1'b1;

flag_count <= 1'b0;

//STATE_RX <= WAIT_BIT;

end

end

endcase

end

end

// parte combinacional RX

always @(*)

begin

NEXT_STATE_RX = STATE_RX;

case(STATE_RX)

WAIT_BIT:

begin

if (!RX) NEXT_STATE_RX = START_BIT;

end

START_BIT:

begin

if (COUNT == 13'd3333)

begin


168

NEXT_STATE_RX = WAIT_BIT;

else

NEXT_STATE_RX = READ_BIT;

end

end

READ_BIT:

begin

if (COUNT == 13'd2)

begin

if (count_data == 4'd8)

begin

NEXT_STATE_RX = PARITY_BIT;

end

end

end

PARITY_BIT:

begin

if (COUNT == 13'd3333)


begin

if ((^DATA_RX) == 1)

NEXT_STATE_RX = STOP_BIT;

else

begin


end

end

else

begin

if ((^DATA_RX) == 0)

NEXT_STATE_RX = STOP_BIT;

else

begin


169

end

end

end

STOP_BIT:

begin

if (COUNT == 13'd3333)


begin


end

else

begin


end

end

endcase

end

//parte sequencial TX


begin

if (!RESET)

begin

COUNT_TX <= 13'd0 ;

TX_BAUD <= 4'd0 ;

STATE_TX <= RECV_NEW_DATA ;

P_DATA <= 8'd0;

TX <= 1'b1;

end

else

begin

STATE_TX <= NEXT_STATE_TX;

case (STATE_TX)

RECV_NEW_DATA:

170

begin

if (DATA_IN != P_DATA)

begin

COUNT_TX <= 13'd0;

P_DATA <= DATA_IN;

TX_BAUD <= 4'd0;

end

else

begin

TX <= 1'b1;

end

end

TRANSMIT_BIT:

begin

if (COUNT_TX == 13'd3333)

begin

TX_BAUD <= TX_BAUD + 4'd1;

COUNT_TX <= 1'b0;

end

else

COUNT_TX <= COUNT_TX + 1'b1;

case (TX_BAUD)

4'd0 : TX <= 1'b0;

4'd1 : TX <= DATA_IN[0];

4'd2 : TX <= DATA_IN[1];

4'd3 : TX <= DATA_IN[2];

4'd4 : TX <= DATA_IN[3];

4'd5 : TX <= DATA_IN[4];

4'd6 : TX <= DATA_IN[5];

4'd7 : TX <= DATA_IN[6];

4'd8 : TX <= DATA_IN[7];

4'd9 : TX <= ^DATA_IN;

4'd10 : TX <= 1'b1;

endcase

171

end

endcase

end

end

//parte combinacional tx

always @(*)

begin

NEXT_STATE_TX=STATE_TX;

case (STATE_TX)

RECV_NEW_DATA : begin

if (DATA_IN != P_DATA)

NEXT_STATE_TX = TRANSMIT_BIT;

end

TRANSMIT_BIT : begin

if(TX_BAUD == 4'd11 | TX_BAUD == 4'd12 | TX_BAUD == 4'd13 | TX_BAUD

== 4'd14 | TX_BAUD == 4'd15)

NEXT_STATE_TX = RECV_NEW_DATA;

end

endcase

end

*/

;_____________________________________________________

`timescale 1ns/1ns

module uart_rx#(

parameter integer WIDTH = 16

)

(

//external input

input PCLK,

input RESET,

input RX_I,

172

input [WIDTH -1:0] WORK_FR,

output reg [7:0] DATA_RX_O,

output reg PARITY_RX,

output READY

);

localparam [3:0] RX_IDLE = 4'b0000,

RX_DETECT_START = 4'b0001,

RX_TAKE_DATA = 4'b0010,

RX_TAKE_PARITY = 4'b0100,

RX_HIGH_DETECT = 4'b1000;

reg [3:0] state_rx;

reg [3:0] next_state_rx;

reg [WIDTH-1:0] COUNTER;

reg [3:0] DATA_COUNTER;

reg AUX;

assign READY = (state_rx == RX_HIGH_DETECT & COUNTER == 12'd2)?1'b1:1'b0;

always@(*)

begin

next_state_rx = state_rx;

case(state_rx)

RX_IDLE:

begin

if(RX_I)

begin

173

next_state_rx = RX_IDLE;

end

else

begin

next_state_rx = RX_DETECT_START;

end

end

RX_DETECT_START:

begin

if(COUNTER == WORK_FR && AUX == 1'b0)

begin

next_state_rx = RX_TAKE_DATA;

end

else if(COUNTER != WORK_FR)

begin

next_state_rx = RX_DETECT_START;

end

else

begin


end

end

RX_TAKE_DATA:

begin

if(COUNTER != WORK_FR && DATA_COUNTER != 4'b1000)

begin


end

else if(COUNTER == WORK_FR && DATA_COUNTER != 4'b1000)

begin

174


end

else if(COUNTER == WORK_FR && DATA_COUNTER == 4'b1000)

begin

next_state_rx = RX_TAKE_PARITY;

end

end

RX_TAKE_PARITY:

begin

if(COUNTER != WORK_FR)

begin

next_state_rx = RX_TAKE_PARITY;

end

else

begin

next_state_rx = RX_HIGH_DETECT;

end

end

RX_HIGH_DETECT:

begin

if(COUNTER != WORK_FR)

begin


end

else if(COUNTER == WORK_FR && AUX == 1'b0)

begin


end

else

begin


end

175

end

default:

begin


end

endcase

end

always@(posedge PCLK)

begin

if(RESET)

begin

state_rx <= RX_IDLE;

COUNTER<= {WIDTH{1'b0}};

DATA_COUNTER<= 4'd0;

DATA_RX_O<=8'd0;

AUX<= 1'b1;

end

else

begin

state_rx <= next_state_rx;

case(state_rx)

RX_IDLE:

begin

if(RX_I)

begin



end

else

176

begin

COUNTER<= COUNTER + 1'b1;

end

end

RX_DETECT_START:

begin

if(COUNTER == WORK_FR/2'd2)

begin

AUX <= RX_I;


end

else if(COUNTER < WORK_FR)

begin


end

else

begin


end

end

RX_TAKE_DATA:

begin

if(DATA_COUNTER != 4'b1000 && COUNTER == WORK_FR/2'd2)

begin

DATA_COUNTER<= DATA_COUNTER+1'b1;

DATA_RX_O[DATA_COUNTER[2:0]]<=RX_I;


end


begin


end

177

else

begin


end

end

RX_TAKE_PARITY:

begin


begin

PARITY_RX <= RX_I;

COUNTER <= COUNTER + 1'b1;

end


begin

COUNTER <= COUNTER + 1'b1;

end

else

begin


AUX <= 1'b0;

end

end

RX_HIGH_DETECT:

begin


begin

AUX <= RX_I;


end


begin

178


end

else

begin


end


end

default:

begin



end

endcase

end

end

endmodule

;_____________________________________________________

`timescale 1ns/1ns

module uart_tx#(

parameter integer WIDTH = 16

)

(

input PCLK,

input RESET,

input [7:0] DATA_TX_I,

input [WIDTH -1:0] WORK_FR,

input START,

output TX_O,

output reg READY_TX

);

179

localparam [11:0] TX_IDLE = 12'b0000_0000_0000,

TX_START = 12'b0000_0000_0001,

TX_BIT_1 = 12'b0000_0000_0010,

TX_BIT_2 = 12'b0000_0000_0100,

TX_BIT_3 = 12'b0000_0000_1000,

TX_BIT_4 = 12'b0000_0001_0000,

TX_BIT_5 = 12'b0000_0010_0000,

TX_BIT_6 = 12'b0000_0100_0000,

TX_BIT_7 = 12'b0000_1000_0000,

TX_BIT_8 = 12'b0001_0000_0000,

TX_PARITY = 12'b0010_0000_0000,

TX_STOP = 12'b0100_0000_0000;

reg [11:0] state_tx;

reg [11:0] next_state_tx;

reg [WIDTH-1:0] DELAY_COUNTER;

assign TX_O = (state_tx == TX_START)?1'b0:

(state_tx == TX_BIT_1)?DATA_TX_I[0:0]:








(state_tx ==

TX_PARITY)?DATA_TX_I[0:0]^DATA_TX_I[1:1]^DATA_TX_I[2:2]^DATA_TX_I[3:3]^DAT

A_TX_I[4:4]^DATA_TX_I[5:5]^DATA_TX_I[6:6]^DATA_TX_I[7:7]:

180

(state_tx == TX_STOP)?1'b1:1'b1;

always@(*)

begin

next_state_tx = state_tx;

case(state_tx)

TX_IDLE:

begin

if(START == 1'b0)

begin

next_state_tx = TX_IDLE;

end

else

begin

next_state_tx = TX_START;

end

end

TX_START:

begin

if(DELAY_COUNTER != WORK_FR)

begin

next_state_tx = TX_START;

end

else

begin

next_state_tx = TX_BIT_1;

end

end

TX_BIT_1:

begin


181

begin


end

else

begin


end

end

TX_BIT_2:

begin


begin


end

else

begin


end

end

TX_BIT_3:

begin


begin


end

else

begin


end

end

182

TX_BIT_4:

begin


begin


end

else

begin


end

end

TX_BIT_5:

begin


begin


end

else

begin


end

end

TX_BIT_6:

begin


begin


end

else

begin


183

end

end

TX_BIT_7:

begin


begin


end

else

begin


end

end

TX_BIT_8:

begin


begin


end

else

begin

next_state_tx = TX_PARITY;

end

end

TX_PARITY:

begin


begin

next_state_tx = TX_PARITY;

end

else

184

begin

next_state_tx = TX_STOP;

end

end

TX_STOP:

begin


begin

next_state_tx = TX_STOP;

end

else

begin


end

end

default:

begin


end

endcase

end

always@(posedge PCLK)

begin

if(RESET)

begin

READY_TX <= 1'b1;

DELAY_COUNTER<= {WIDTH{1'b0}};

state_tx <= TX_IDLE;

end

185

else

begin

state_tx <= next_state_tx;

case(state_tx)

TX_IDLE:

begin

if(START == 1'b0)

begin

READY_TX<= 1'b1;


end

else

begin

READY_TX<= 1'b0;

DELAY_COUNTER <= DELAY_COUNTER + 1'b1;

end

end

TX_START:

begin

if(DELAY_COUNTER < WORK_FR)

begin


end

else

begin


end

end

TX_BIT_1:

begin


begin


186

end

else

begin


end

end

TX_BIT_2:

begin


begin


end

else

begin


end

end

TX_BIT_3:

begin


begin


end

else

begin


end

end

TX_BIT_4:

begin


begin


end

187

else

begin


end

end

TX_BIT_5:

begin


begin


end

else

begin


end

end

TX_BIT_6:

begin


begin


end

else

begin


end

end

TX_BIT_7:

begin


begin


end

else

188

begin


end

end

TX_BIT_8:

begin


begin


end

else

begin

DELAY_COUNTER <= {WIDTH{1'b0}};

end

end

TX_PARITY:

begin


begin


end

else

begin

DELAY_COUNTER <= {WIDTH{1'b0}};

end

end

TX_STOP:

begin


begin


end

else

begin

189


end

end

default:

begin


end

endcase

end

end

endmodule

190

Apêndice B

CÓDIGO fonte feito em E language (ambiente de validação);

unit csp_agent_adc_u like any_unit {

// evento do clock

event clk_e;

// definicao do agente como ACTIVE ou PASSIVE

active_passive: erm_active_passive_t;

keep soft active_passive == PASSIVE;

// definindo instacias do signal map e do monitor

sig: csp_signal_map_u;

mon: csp_monitor_adc_u is instance;

//conectando as portas

keep mon.adc_p == read_only(sig.adc_p);

keep mon.trigger_p == read_only(sig.trigger_p);

// conectando o parent

keep mon.parent == me;

when ACTIVE csp_agent_adc_u {

// definindo instacia da BFM e sequence generator (driver)

bfm: csp_bfm_adc_u is instance;


keep bfm.adc_p == read_only(sig.adc_p);

keep bfm.trigger_p == read_only(sig.trigger_p);

191


keep bfm.parent == me;

};

};

-- passando o clock do agente para o monitor

extend csp_monitor_adc_u {

parent: csp_agent_adc_u;

event clk_e is only @parent.clk_e;

};

-- passando o clock do agente para a bfm

extend csp_bfm_adc_u {

parent: csp_agent_adc_u;


};

'>

;_____________________________________________________

<'

unit csp_agent_pwm_u like any_unit {

// evento do clock

event clk_e;



mon: csp_monitor_pwm_u is instance;

mon_stab: csp_monitor_stabilizer_u is instance;


keep mon.pwm_p == read_only(sig.pwm_p);

keep mon_stab.flag_out_ok_p== read_only(sig.flag_out_ok_p);



192

};


extend csp_monitor_pwm_u {

parent: csp_agent_pwm_u;


};

'>

;_____________________________________________________

<'

unit csp_agent_serial_u like any_unit {

// evento do clock

event clk_e;

// definicao do agente como ACTIVE ou PASSIVE

active_passive: erm_active_passive_t;

keep soft active_passive == PASSIVE;



mon: csp_mon_serial_u is instance;


keep mon.serial_tx_p == read_only(sig.serial_tx_p);

keep mon.serial_rx_p == read_only(sig.serial_rx_p);

keep mon.serial_error_p == read_only(sig.serial_error_p);



when ACTIVE csp_agent_serial_u {

// definindo instacia da BFM e sequence generator (driver)

bfm: csp_bfm_serial_u is instance;

193


keep bfm.serial_rx_p == read_only(sig.serial_rx_p);

keep bfm.serial_error_p == read_only(sig.serial_error_p);


keep bfm.parent == me;

};

};


extend csp_mon_serial_u {

parent: csp_agent_serial_u;


};

-- passando o clock do agente para a bfm

extend csp_bfm_serial_u {

parent: csp_agent_serial_u;


};

'>

;_____________________________________________________

<'

unit csp_bfm_adc_u like any_unit{

-- evento de clock

event clk_e;

-- evento de envio para a dut de um pacote

event input_sended_e;

-- ponteiro para o driver

drive: csp_adc_driver_u is instance;

194

-- definicao de uma variavel randomica

random_value: uint;

keep random_value in [200 .. 300];

-- declaracao das portas a serem driviadas

adc_p : inout simple_port of byte;

trigger_p : inout simple_port of bit;

-- criacao do metodo que vai enviar para a dut os pacotes

drive_bus() @clk_e is {

-- definicao de uma variavel que recebe os valores do driver e que vai ser enviado para a dut

var input_data: csp_adc_s;

while (TRUE) {

wait [random_value];

-- emite este evento que e um evento predefinido no drive e gera um item de dados

emit drive.clock;

-- este metodo faz com o item de dados gerado no driver seja colocada na variavel e em seguida

enviado para a dut

input_data = drive.get_next_item();

wait [64];

adc_p$ = input_data.adc;

trigger_p$ = 1;

wait [1];

trigger_p$ = 0;

-- envia valores de input_data para a DUT

-- emite um evento no drive informando que o item de dados produzido pelo drive ja foi utili-

zado e que ele pode produzir um novo item

195

emit drive.item_done;

-- emite um evento de controle

emit input_sended_e;

};

};

run() is {

start drive_bus();

};

};

'>

;_____________________________________________________

<'

unit csp_bfm_reset_u like any_unit

{

--------------------------------------

-- Clock event to sync whit BFM

--------------------------------------

event clk_e;

--------------------------------------

-- Creating pointers

--------------------------------------

reset_p: inout simple_port of bit;

--------------------------------------

-- Creating variable to control reset time

--------------------------------------

!periods_active:uint;

196

keep periods_active in [1 .. 50];

!periods_wait:uint;

keep periods_wait in [500 .. 1000];

!reset_qtde:uint;

keep reset_qtde == 4;

--------------------------------

-- TCM drive bus

--------------------------------


------------------------------------

-- Initial procedure to reset

------------------------------------

reset_p$ = 1;

wait[2];

reset_p$ = 0;

gen reset_qtde;

-------------------------------------

-- loop to the next resets

-------------------------------------

for i from 1 to reset_qtde {

gen periods_wait;

wait [periods_wait];

gen periods_active;

reset_p$ = 1;

wait [periods_active];

reset_p$ = 0;

197

};

};

run() is also {

reset_p$ = 1;

start drive_bus();

};

};

'>

;_____________________________________________________

<'

unit csp_bfm_serial_u like any_unit{

-- evento de clock

event clk_e;

-- evento de envio para a dut de um pacote

event input_sended_e;

-- ponteiro para o driver

drive: csp_serial_driver_u is instance;

-- definicao de uma variavel randomica

198

random_value: uint;

keep random_value in [5000 .. 9000];

-- declaracao das portas a serem driviadas

serial_rx_p : inout simple_port of bit;

serial_error_p: inout simple_port of bit;

-- criacao do metodo que vai enviar para a dut os pacotes


-- definicao de uma variavel que recebe os valores do driver e que vai ser enviado para a dut

var input_data: csp_serial_s;

while (TRUE) {

gen random_value;

wait [random_value];

-- emite este evento que e um evento predefinido no drive e gera um item de dados

emit drive.clock;

-- este metodo faz com o item de dados gerado no driver seja colocada na variavel e em seguida

enviado para a dut

input_data = drive.get_next_item();

-- envia valores de input_data para a DUT

199

print input_data;

serial_rx_p$ = input_data.start_bit;

wait [651];

for i from 0 to 7 {

serial_rx_p$ = input_data.data[i:i];

wait [651];

};

serial_rx_p$ = input_data.parity;

wait [651];

serial_rx_p$ = input_data.stop_bit;

wait [651];

-- emite um evento no drive informando que o item de dados produzido pelo drive ja foi utili-

zado e que ele pode produzir um novo item

emit drive.item_done;

-- emite um evento de controle

emit input_sended_e;

};

};

run() is {

start drive_bus();

200

};

};

'>

;_____________________________________________________

<'

unit csp_checker_u like any_unit {

// evento clock

event clk_e;

// criando method_ports de entrada

get_serial_rx: in method_port of serial_pipe is instance;

keep bind(get_serial_rx, empty);

get_serial_tx: in method_port of serial_pipe is instance;

keep bind(get_serial_tx, empty);

get_adc : in method_port of adc_pipe is instance;

keep bind(get_adc, empty);

get_pwm : in method_port of pwm_pipe is instance;

keep bind(get_pwm, empty);

get_flag_ok : in method_port of flag_pipe is instance;

keep bind(get_flag_ok, empty);

201

//_____________________________________________________________________

!input_serial : csp_serial_s;

!output_serial: csp_serial_s;

!input_adc : csp_adc_s;

!input_pwm : csp_pwm_s;

!output_flag : bit;

!expected_flag: bit;

//_____________________________________________________________________

//sinais internos

!list_pid_erros[3]: list of int(bits:9);

!list_stab[10]: list of bit;

!list_softstart[10]: list of bit;

!softstart_output: uint(bits:8);

!result_comp: int(bits:9);

!control_signal_at: int(bits:18);

202

!control_signal_pre: int(bits:18);

!kp: uint(bits:16);

!ki: uint(bits:16);

!kd: uint(bits:16);

!v_desired: uint(bits:8);

//auxiliar

!conv_adc: bool;

//valores apos o reset atribuidos aqui

run() is also {

input_serial=new;

output_serial=new;

input_adc =new;

input_pwm =new;

output_flag = 0;

expected_flag = 0;

203

kp=0;

ki=8;

kd=0;

list_pid_erros[0] =0;



for i from 0 to 9 {

list_softstart[i] = 0;

list_stab[i] = 0;

};

softstart_output = 0;

result_comp = 0;

control_signal_at = 0;

control_signal_pre = 0;

v_desired = 0;

conv_adc = FALSE;

start do_check();

};

//_____________________________________________________________________

event serial_in_received_e;

get_serial_rx(serial:csp_serial_s, serial_error:bit) is {

204

-- print serial;

-- print serial_error;

-- print serial.parity_calc();

-- if (serial.parity == serial.parity_calc()) {

if (serial.csp_kind == GOOD) {

input_serial = serial;

emit serial_in_received_e;

check that (serial_error == 0) else dut_error("Erro na recepcao da Serial. Error_serial deveria ser

0, mas recebeu 1");

}

else {

check that (serial_error == 1) else dut_error("Erro na recepcao da Serial. Error_serial deveria ser

1, mas recebeu 0");

};

};

//_____________________________________________________________________

event serial_out_received_e;

get_serial_tx(serial:csp_serial_s, serial_error:bit) is {

output_serial = serial;

emit serial_out_received_e;

};

//_____________________________________________________________________

get_flag_ok(flag:bit) is {

205

output_flag = flag;

check that output_flag == expected_flag else dut_error("Output Stable flag is wrong. Expected ",

expected_flag, " but obtained ", output_flag);

};

//_____________________________________________________________________

get_adc(adc:csp_adc_s,trigger:bit) is {//acontece em cada ciclo do adc

input_adc = adc;

var desired_value:uint(bits:8) = input_serial.data;

result_comp = desired_value - input_adc.adc;

//parte checagem stablizer

list_stab.delete(0);

if(result_comp <= 7 and result_comp >= -7){list_stab.push(1);}

else {list_stab.push(0);};

if(list_stab.and_all(it==1)){expected_flag = 1;}

else {expected_flag = 0;};

//parte checagem stablizer

//parte checagem soft start

var result_comp_soft_start:int = softstart_output - input_adc.adc;

206

if(result_comp_soft_start <= 7 and result_comp_soft_start >= -7){list_softstart.push(1);}

else {list_softstart.push(0);};

if(list_softstart.and_all(it==1)){

case {

(softstart_output > desired_value + 51) : { softstart_output = softstart_output + 51;};

(softstart_output < desired_value - 51) : { softstart_output = softstart_output - 51;};

(abs(softstart_output - desired_value) < 51) : { softstart_output = desired_value;};

};

};

//parte checagem soft start

//parte checagem do pid

list_pid_erros.add0 (result_comp_soft_start);//ultimo erro baseado na diferenca do valor desejado

com o soft start

list_pid_erros.delete(3);//grava os 3 ultimos erros

control_signal_pre = control_signal_at;

control_signal_at = control_signal_pre + kp*list_pid_erros[0]+ ki*list_pid_erros[1] +

kd*list_pid_erros[2];

var t: int = kp*list_pid_erros[0]+ ki*list_pid_erros[1] + kd*list_pid_erros[2];

207

if (t > 0 and control_signal_at < 0 ){

control_signal_at = 18'b01_1111_1111_1111_1111;//se estourou para cima

} else

{

if ( t < 0 and control_signal_at < 0 ){

control_signal_at = 0;//se estourou para baixo

};

};

//parte checagem do pid

conv_adc= TRUE; //Para previnir que a primeira leitura leitura do pwm depois da conversao do

ADC esteja errada

-- print trigger;

-- print sys.time;

-- print result_comp;

-- print input_serial.data;

-- print input_adc.adc;

-- print list_pid_erros;

-- print control_signal_at;

-- print bin(control_signal_at);

-- print bin (control_signal_at[16:11]);

-- print control_signal_at[16:11];

}; //_____________________________________________________________________

get_pwm(pwm:csp_pwm_s) is {

input_pwm = pwm;

208

if(conv_adc){ conv_adc = FALSE;} //Para previnir que a primeira leitura leitura do pwm depois

da conversao do ADC esteja errada

else{

check that (input_pwm.pwm == control_signal_at[16:11]) else dut_error("Error na saida PWM.

Esperado:",control_signal_at[16:11]," Obtido:", input_pwm.pwm);

};

};

// decoding opcode (DRA) para fazer escrita, sendo 4 primeiros opcodes(0'b1010_0000,

0'b1010_0001, 0'b1010_0010, 0'b1010_0011);

// decoding opcode (DRA) para fazer leitura, sendo 2 ultimos opcodes(0'b1010_0100,

0'b1010_0101);

do_check() @sys.any is {

var list_of_serial: list of csp_serial_s;

while(TRUE){

wait @serial_in_received_e;

--print input_serial;

case input_serial.data{

8'b1010_0000:{


v_desired = input_serial.data;


};

8'b1010_0001:{


var temp1:byte = input_serial.data;



209



ki = %{temp1,temp2};

};

8'b1010_0010:{







kp = %{temp1,temp2};

};

8'b1010_0011:{







kd = %{temp1,temp2};

};

8'b1010_0100:{

start check_output_serial(input_adc.adc,input_serial.data); --ADC

};

210

8'b1010_0101:{

start check_output_serial(%{2'b0,control_signal_at[17:12]},input_serial.data); --PID

};

};

list_of_serial.add(input_serial);

};

};

//verifica se a saida da serial (uart), e mesmo o valor esperado, caso nao, emite mensagem de erro;

check_output_serial(val:byte, opcode:byte)@serial_out_received_e is{

check that val == output_serial.data else dut_error("Saida da serial esta errada.\nValor esperado:

", val, "\nValor obtido: ", output_serial.data, "\nOpcode: ",opcode);

};

};

'>

;_____________________________________________________

<'

import csp_top;

extend sys {

// Instanciar o env

env: csp_env_u is instance;

keep env.hdl_path() == "~/tb_csp/utt_top_csp";

//configurar agentes

keep env.agent_adc.active_passive == PASSIVE;

211

keep env.agent_serial.active_passive == PASSIVE;

setup() is also {

// a linha abaixo seta a variavel tick_max do specman para o maior numero inteiro possível.

// o metodo set_config pode ser utilizado para setar muitas outras variáveis de configuração.

// pode por exemplo configurar a variável verbosity das messages. Acesse cdnshelp para saber

mais.

set_config(run, tick_max, MAX_INT);

// a linha abaixo muda o modo como as coberturas são apresentadas.

set_config(cover, specview_cover_window, TRUE);

};

};

'>

;_____________________________________________________

<'

import csp_top;

import csp_test;

extend sys {

// Instanciar o env

env: csp_env_u is instance;

keep env.hdl_path() == "~/tb_csp";

212

//configurar agentes

keep env.agent_adc.active_passive == ACTIVE;

keep env.agent_serial.active_passive == ACTIVE;

keep env.reset_type == ACTIVE;

setup() is also {

// a linha abaixo seta a variavel tick_max do specman para o maior numero inteiro possivel.

// o metodo set_config pode ser utilizado para setar muitas outras variaveis de configuracao.

// pode por exemplo configurar a variavel verbosity das messages. Acesse cdnshelp para saber

mais.

set_config(run, tick_max, MAX_INT);

// a linha abaixo muda o modo como as coberturas são apresentadas.

set_config(cover, specview_cover_window, TRUE);

};

};

'>

;_____________________________________________________

<'

sequence csp_serial_seq_s using

item = csp_serial_s,

created_driver = csp_serial_driver_u,

created_kind = csp_serial_seq_kind_t;

sequence csp_adc_seq_s using

213

item = csp_adc_s,

created_driver = csp_adc_driver_u,

created_kind = csp_adc_seq_kind_t;

'>

;_____________________________________________________

<'

type processor_reset_type: [ACTIVE_RESET, PASSIVE_RESET];

unit csp_env_u like any_env {

// evento de clock

event clk_e is true(sync.reset_p$ == 0)@sync.clk_p$;

event unqualified_clk_e is @sync.clk_p$;

// deteccao de reset

event reset_start is @sync.reset_fall_p$;

event reset_stop is @sync.reset_rise_p$;

// campos auxiliares

!reset_actve:bool;

// acoes auxiliares

on reset_start {reset_actve = TRUE; };

on reset_stop {reset_actve = FALSE;};

214

run() is also{

reset_actve = TRUE;

};

// evento de clock só acontece quando nào estiver em reset nem em hold

--event clk_e is only true(not reset_actve)@sync.clk_p$;

event clk_change_e is true(not reset_actve)@sync.clk_change_p$;

//criando instancias do signal map, dos agentes e do checker

sig :csp_signal_map_u is instance;

agent_pwm :csp_agent_pwm_u is instance;

agent_serial :csp_agent_serial_u is instance;

agent_adc :csp_agent_adc_u is instance;

checker :csp_checker_u is instance;

sync :csp_sync_u is instance;

// conectando os signal map aos agentes

keep agent_pwm.sig == read_only(sig);

keep agent_serial.sig == read_only(sig);

keep agent_adc.sig == read_only(sig);

keep agent_pwm.parent == me;

keep agent_serial.parent == me;

keep agent_adc.parent == me;

215

keep checker.parent == me;

// conectando environment ao checker

connect_ports() is also {

do_bind( agent_adc.mon.send_adc , checker.get_adc );

do_bind( agent_pwm.mon.send_pwm , checker.get_pwm );

do_bind( agent_pwm.mon_stab.send_flag_ok , checker.get_flag_ok );

do_bind( agent_serial.mon.send_serial_rx , checker.get_serial_rx );

do_bind( agent_serial.mon.send_serial_tx , checker.get_serial_tx );

};

//quando acontecer o reset, resetar o environment

on reset_start{

agent_pwm.rerun();

agent_serial.rerun();

agent_adc.rerun();

checker.rerun();

};

---------------------------

-- Creating a reset type

---------------------------

reset_type:erm_active_passive_t;

216

keep soft reset_type == PASSIVE;

---------------------------

-- Defining again what we already did on reset bfm

---------------------------

when ACTIVE'reset_type csp_env_u {

reset_bfm:csp_bfm_reset_u is instance;

keep reset_bfm.reset_p == read_only(sync.reset_p);

keep reset_bfm.parent == me;

};

};

extend csp_agent_pwm_u{

parent: csp_env_u;

event clk_e is only @parent.clk_change_e;

//propagando o reset para o monitor

rerun() is also{

mon.rerun();

};

};

217

extend csp_agent_adc_u{

parent: csp_env_u;



rerun() is also{

mon.rerun();

};

//propagando o reset para a bfm

when ACTIVE csp_agent_adc_u {

// reiniciando a bfm

rerun() is also{

bfm.rerun();

};

};

};

extend csp_agent_serial_u{

parent: csp_env_u;



rerun() is also{

218

mon.rerun();

};

//propagando o reset para a bfm

when ACTIVE csp_agent_serial_u {

// reiniciando a bfm

rerun() is also{

bfm.rerun();

};

};

};

extend csp_checker_u{

parent: csp_env_u;


};

-- Extend BFM

-------------------------------------------

extend csp_bfm_reset_u {

parent:csp_env_u;

event clk_e is only @parent.unqualified_clk_e;

};

219

'>

;_____________________________________________________

<'

type csp_kind_t: [GOOD, BAD];

struct csp_serial_s like any_sequence_item{

%start_bit: bit ;

%data : byte;

%parity : bit ;

%stop_bit : bit ;

csp_kind: csp_kind_t;

keep soft start_bit == 0;

keep soft stop_bit == 1;

keep soft csp_kind == GOOD;

keep csp_kind == GOOD => parity == parity_calc();

keep csp_kind == BAD => parity != parity_calc();

parity_calc():bit is {

result = bitwise_xor(data);

};

};

struct csp_adc_s like any_sequence_item {

%adc: byte;

};

struct csp_pwm_s {

220

%pwm: uint(bits:6);

};

'>

;_____________________________________________________

<'

method_type serial_pipe(serial:csp_serial_s, serial_error:bit);

method_type adc_pipe(adc:csp_adc_s,trigger:bit);

method_type pwm_pipe(pwm:csp_pwm_s);

method_type flag_pipe(flag_ok:bit);

'>

;_____________________________________________________

<'

unit csp_monitor_adc_u like any_unit{

// vento clock para synchronizar o monitor

event clk_e;

//portas para connecao com a DUT

adc_p : inout simple_port of byte;

trigger_p : inout simple_port of bit;

//method Type para connectar com o checker

send_adc: out method_port of adc_pipe is instance;

keep bind(send_adc, empty);

!input : csp_adc_s;

221

event data_detected_e;

watch_bus() @clk_e is {

message(HIGH,"Starting to watch ADC Bus");

while (TRUE) {

wait true (trigger_p$ == 1);

gen input keeping{

.adc == adc_p$;

};

emit data_detected_e;

send_adc$(input,trigger_p$);

message(HIGH,"Data Memory detected.");

wait [1];

};

};

run() is also {start watch_bus()};

};

'>

;_____________________________________________________

<'

unit csp_monitor_pwm_u like any_unit{

//clock event to synchronize the monitor

event clk_e;

//ports to connect to the DUT

pwm_p: inout simple_port of bit;

//method Type to connect to the checker

send_pwm: out method_port of pwm_pipe is instance;

keep bind(send_pwm, empty);

!input : csp_pwm_s;

222

!input_2: csp_pwm_s;

count : uint;

event data_detected_e;


input = new;

message(HIGH,"Starting to watch ADC Bus");

var lob: list of bit;

while (TRUE) {

for i from 1 to 63 {

lob.add(pwm_p$);

count = i;

wait [1];

};

input.pwm = lob.count(it == 1);

lob.clear();

emit data_detected_e;

send_pwm$(input);

message(HIGH,"Data Memory detected.");

wait [1];

};

};

-- watch_bus_2() @clk_e is {

-- message(HIGH,"Starting to watch ADC Bus");

-- while (TRUE) {

-- input_2.pwm = 0;

-- for i from 1 to 64 {

-- input_2.pwm = input_2.pwm + pwm_p$;

-- wait [1];

-- };

223

-- emit data_detected_e;

-- print input_2;

--send_pwm$(input);

-- message(HIGH,"Data Memory detected.");

-- wait [1];

-- };

-- };

run() is also {

start watch_bus();

-- start watch_bus_2();

};

};

'>

;_____________________________________________________

<'

unit csp_mon_serial_u like any_unit{

-- evento de clock

event clk_e;

-- evento de deteccao de entrada

event input_detect_e;

-- declaracao das portas a serem monitoradas

serial_tx_p : inout simple_port of bit;

serial_rx_p : inout simple_port of bit;

serial_error_p: inout simple_port of bit;

-- item de dados

!input: csp_serial_s;

-- Definacao do method_port (instancia) de saida para o checker

send_serial_rx: out method_port of serial_pipe is instance;

224

keep bind(send_serial_rx, empty);

send_serial_tx: out method_port of serial_pipe is instance;

keep bind(send_serial_tx, empty);

-- declaracao e construcao do metodo que vai ficar observando o barramento de entrada o tempo

inteiro

-- e enviar um pacote para o checker

watch_bus_rx() @clk_e is {

var lob: list of bit; // observar se e necessario alterar este bloco???

while (TRUE) {

wait true(serial_rx_p$ == 0);


-- wait[104];

wait [1666];

lob.add(serial_rx_p$);

wait [1667];

--wait[104];

--wait [208];

};

unpack(packing.low,lob,input);

send_serial_rx$(input, serial_error_p$);

lob.clear();

-- print input;

emit input_detect_e;

};

};

watch_bus_tx() @clk_e is {

var lob: list of bit;

225

while (TRUE) {

wait true(serial_tx_p$ == 0);


wait [1666];

lob.add(serial_tx_p$);

wait [1667];

--wait [3333];

};

unpack(packing.low,lob,input);

send_serial_tx$(input, 0);

lob.clear();

emit input_detect_e;

};

};

run() is also {

start watch_bus_rx();

start watch_bus_tx();

};

};

'>

;_____________________________________________________

<'

unit csp_monitor_stabilizer_u like any_unit{

// vento clock para synchronizar o monitor

event clk_e;

//portas para connecao com a DUT

flag_out_ok_p : inout simple_port of bit;

//method Type para connectar com o checker

send_flag_ok: out method_port of flag_pipe is instance;

226

keep bind(send_flag_ok, empty);

event flag_detected_e;


message(HIGH,"Starting to watch flag Bus");

while (TRUE) {

wait [1];

emit flag_detected_e;

send_flag_ok$(flag_out_ok_p$);

message(HIGH,"Flag detected.");

};

};

run() is also {start watch_bus()};

};

'>

;_____________________________________________________

<'

extend csp_serial_seq_kind_t : [PROGRAM_V];

extend PROGRAM_V csp_serial_seq_s

{

!seq_item:csp_serial_s;

body()@driver.clock is only{

do seq_item keeping{

.data == 8'b1010_0000;

.csp_kind == GOOD;

};

do seq_item;

};

};

extend csp_serial_seq_kind_t :[PROGRAM_KP];

extend PROGRAM_KP csp_serial_seq_s

{

227




.data == 8'b1010_0010;

.csp_kind == GOOD;

};

do seq_item;

do seq_item;

};

};

extend csp_serial_seq_kind_t :[PROGRAM_KI];

extend PROGRAM_KI csp_serial_seq_s

{




.data == 8'b1010_0001;

.csp_kind == GOOD;

};

do seq_item;

do seq_item;

};

};

extend csp_serial_seq_kind_t :[PROGRAM_KD];

extend PROGRAM_KD csp_serial_seq_s

{




.data == 8'b1010_0011;

.csp_kind == GOOD;

};

228

do seq_item;

do seq_item;

};

};

extend csp_serial_seq_kind_t :[READ_ADC];

extend READ_ADC csp_serial_seq_s

{




.data == 8'b1010_0100;

.csp_kind == GOOD;

};

};

};

extend csp_serial_seq_kind_t :[READ_PID];

extend READ_PID csp_serial_seq_s

{




.data == 8'b1010_0101;

.csp_kind == GOOD;

};

};

};

extend csp_serial_seq_kind_t :[NOTHING];

extend NOTHING csp_serial_seq_s

{


229



.data not in [8'b1010_0000 .. 8'b1010_0101];

};

};

};

extend csp_serial_seq_kind_t :[BAD];

extend BAD csp_serial_seq_s

{




.csp_kind == BAD;

};

};

};

'>

;_____________________________________________________

<'

unit csp_signal_map_u like any_unit{

//TODO alterar hdl paths

serial_tx_p: inout simple_port of bit is instance;

keep bind (serial_tx_p, external);

keep serial_tx_p.hdl_path() == "top_serial_o";

serial_rx_p: inout simple_port of bit is instance;

keep bind (serial_rx_p, external);

keep serial_rx_p.hdl_path() == "top_serial_i";

adc_p: inout simple_port of byte is instance;

keep bind (adc_p, external);

keep adc_p.hdl_path() == "top_adc_i";

230

trigger_p: inout simple_port of bit is instance;

keep bind (trigger_p, external);

keep trigger_p.hdl_path() == "top_enable_i";

serial_error_p: inout simple_port of bit is instance;

keep bind (serial_error_p, external);

keep serial_error_p.hdl_path() == "top_serial_error_o";

flag_out_ok_p: inout simple_port of bit is instance;

keep bind (flag_out_ok_p, external);

keep flag_out_ok_p.hdl_path() == "top_flag_ok_o";

pwm_p: inout simple_port of bit is instance;

keep bind (pwm_p, external);

keep pwm_p.hdl_path() == "top_pwm_o";

};

'>

;_____________________________________________________

<'

unit csp_sync_u like any_unit{

clk_p: in event_port is instance;

keep bind (clk_p, external);

keep clk_p.hdl_path() == "top_clk_i";

keep clk_p.edge() == rise;

clk_change_p: in event_port is instance;

keep bind (clk_change_p, external);

keep clk_change_p.hdl_path() == "top_clk_i";

keep clk_change_p.edge() == change;

reset_p: inout simple_port of bit is instance;

231

keep bind (reset_p, external);

keep reset_p.hdl_path() == "top_reset_i";

reset_fall_p: in event_port is instance;

keep bind (reset_fall_p, external);

keep reset_fall_p.hdl_path() == "top_reset_i";

keep reset_fall_p.edge() == fall;

reset_rise_p: in event_port is instance;

keep bind (reset_rise_p, external);

keep reset_rise_p.hdl_path() == "top_reset_i";

keep reset_rise_p.edge() == rise;

};

'>

;_____________________________________________________

<'

import csp_config_2.e;

extend MAIN csp_serial_seq_s {

!a_sequence : csp_serial_seq_s;

pre_body() @sys.any is first {

driver.raise_objection(TEST_DONE);

};

post_body() @sys.any is also {

driver.drop_objection(TEST_DONE);

};

body() @driver.clock is only {

232

for i from 0 to 5{

do PROGRAM_V a_sequence;

do PROGRAM_KP a_sequence;

do PROGRAM_KI a_sequence;

do PROGRAM_KD a_sequence;

do READ_ADC a_sequence;

do READ_PID a_sequence;

do NOTHING a_sequence;

do BAD a_sequence;

};

for i from 0 to 100{

do a_sequence keeping { .kind in [PRO-

GRAM_V,PROGRAM_KP,PROGRAM_KI,PROGRAM_KD,READ_ADC,READ_PID,NOTHIN

G,BAD];};

};

message(HIGH, "Finished CSP Test Case 1");

};

};

extend MAIN csp_adc_seq_s {

!a_sequence : csp_adc_seq_s;

keep a_sequence.kind in [SIMPLE];

body() @driver.clock is only {

while TRUE {

do a_sequence;

};

message(HIGH, "Finished CSP Test Case 1");

};

};

'>

;_____________________________________________________

<'

import csp_itens;

233

import csp_signal_map;

import csp_sync;

import csp_method_types;

import csp_monitor_pwm;

import csp_monitor_adc;

import csp_monitor_serial;

import csp_monitor_stabilizer;

import csp_driver;

import csp_bfm_serial;

import csp_bfm_adc;

import csp_bfm_reset;

import csp_agent_serial;

import csp_agent_pwm;

import csp_agent_adc;

import csp_checker;

import csp_env;

import csp_seq_lib;

'>

· ii UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO...

Documents

Transcript of · ii UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO...