tiago emanuel lobo de macedo freitas castro

Tiag

o Em

anue

l Lob

o de

Mac

edo

Freit

as C

astro

Outubro de 2012UMin

ho |

201

2

Universidade do MinhoEscola de Engenharia

Tiago Emanuel Lobo de Macedo Freitas Castro

Microcontrolador 8051 e customizávellow power

Mic

roco

ntro

lado

r 80

51

e

cus

tom

izáv

ello

w p

ower

Outubro de 2012

Tese de MestradoCiclo de Estudos Integrados Conducentes ao Grau deMestre em Engenharia Eletrónica Industrial e Computadores

Trabalho efetuado sob a orientação doProfessor Doutor Adriano Tavares

Universidade do MinhoEscola de Engenharia

Tiago Emanuel Lobo de Macedo Freitas Castro

Microcontrolador 8051 e customizávellow power

iii

Agradecimentos

Em primeiro lugar gostaria de agradecer ao meu orientador Professor Doutor Adriano

Tavares não só pela proposta que deu origem a esta dissertação mas também por todo o seu

apoio, partilha de conhecimento e excecional caracter motivador.

Ao Professor Doutor Jorge Cabral por desde cedo ter apostado no meu trabalho tendo

contribuído para o meu crescimento como pessoa e como engenheiro, revelando-se mais do que

um mentor, um amigo.

Aos meus colegas de curso e amigos: Sandro Pinto, Vitor Veiga, Filipe Alves, Rui Costa,

Christophe Fernandes e Rui Araújo que me acompanharam desde cedo no percurso académico,

pelo seu apoio, amizade e incentivo para vencer as adversidades do percurso.

Aos colegas de laboratório do grupo de Sistemas Embebidos, em especial Nuno Brito,

Nuno Cardoso, e Tiago Gomes, pela passagem de experiência, apoio e amizade criada onde nunca

faltou humor e boa disposição.

A todos os meus familiares próximos que sempre me apoiaram, apostaram no meu

sucesso académico sem qualquer tipo de pressão e em todo o percurso da minha vida,

transmitindo-me confiança e alegria sem a qual não é possível vencer batalhas que a vida nos

lança.

A todos, o meu muito obrigado.

v

Resumo

Nos dias de hoje, a maioria dos dispositivos eletrónicos comportam sistemas embebidos. Podem-se encontrar em relógios de pulso, telefones, micro-ondas, computadores e automóveis cobrindo uma ampla gama de aplicabilidade. No entanto, cada sistema embebido é único e especializado para determinado hardware e domínio de aplicação. Assim sendo, as ferramentas de desenvolvimento de software para os mesmos, devem ser adequadas a cada um.

Na sociedade tecnologicamente avançada em que vivemos, os sistemas embebidos de tempo real tornaram-se omnipresentes, havendo por parte dos utilizadores destes, uma constante exigência em termos da duração energética dos mesmos. Como tal, existe uma procura virtual por dispositivos power aware capazes de ombrear a durabilidade energética com o guloso desempenho [1]. Em condições adversas de funcionamento, tal como em dispositivos autoalimentados, a baixa dissipação de potência torna-se uma restrição para a criação de um produto com sucesso, como por exemplo, no caso dos telemóveis. É neste sentido que o trabalho desta dissertação se focará, investigando os efeitos de várias estratégias power aware aquando do desenho de um microcontrolador baseado na ISA (Instruction Set Architecture ) 8051 sem descurar outras métricas como funcionalidade e desempenho. Esta dissertação é parte integrante de um projeto que comporta ainda o porting e upgrade de um sistema operativo para o microcontrolador desenvolvido e ainda uma ferramenta IDE (Integrated Development Environment). Esta é responsável por otimizar em uníssono o microcontrolador com o sistema operativo de acordo com as métricas desejadas pelo utilizador [2].

Assim sendo, o principal foco desta dissertação é a procura de diferentes soluções arquiteturais e microarquitecturais para reduzir os consumos de potência estáticos e dinâmicos. Estas são dependentes da ferramenta EDA (Electronic Design Automation) e do processo tecnológico alvo. Por exemplo, os processos CMOS (Complementary Metal-Oxide Semiconductor) tornaram-se o standard na indústria substituindo nMOS e processos bipolares devido à baixa dissipação de energia dos transístores CMOS. Todavia, esta dissipação passa a ser mesurável devido à quantidade elevada de transístores nos sistemas atuais. Em adição, o tamanho reduzido destes impossibilita que se desliguem completamente promovendo pequenas correntes residuais que são multiplicadas por milhares ou milhões de transístores. Para combater estes desafios atuais, serão exploradas estratégias como: (1) codificação de estados para reduzir a distância de hamming entre instruções subsequentes; (2) clock-gating para disconectar flip flops da árvore de relógio reduzindo a potência dissipada pelos flip flops e pela própria árvore de relógio; (3) power gating para desligar completamente determinados subsistemas do microcontrolador que não sejam necessários a dado momento consumindo desnecessariamente energia; (4) core assíncrono para reduzir o clock skew e remover a árvore de relógio que requer quantidade considerável de área de silício (aumentando a dissipação de potência) e limita a frequência máxima de operação; (5) um algoritmo capaz de escalar a tensão e frequência de funcionamento do microcontrolador on the fly, de acordo com a carga do sistema.

As estratégias supra mencionadas serão aplicadas ao nível da programação HDL (Hardware Description Language) sendo impulsionadas por uma técnica de programação generativa que permite gerir o código fonte codificado em alto nível em prol de uma capacidade superior de customização das funcionalidades do microcontrolador [3] [4].

Para verificar os resultados são utilizadas várias ferramentas EDA que permitem aferir sobre a dissipação de potência assim como o desempenho das várias versões do microcontrolador a ser desenvolvido.

Palavras Chave: sistemas embebidos, microcontrolador 8051, low power, power aware, codificação

de estados, clock gating, power gating, DVFS, Verilog HDL, programação generativa

vii

Abstract

Embedded systems are present in almost every electronic device nowadays. We can find them hidden in our watches, mobile phones, cars, laptops, microwaves… covering a wide range of applicability. However, each embedded system is unique and highly specialized to certain hardware and application domains. Accordingly, the software development tools must be suitable for each of them.

In today’s advanced technological age, embedded and real time systems have become ubiquitous. As a result there is an ever growing need of low power capabilities, thus presenting a virtual demand for power-aware devices [1]. In harsh conditions, such as the ones withstood by self-powered devices, low power is not a requirement anymore thus becoming a constraint instead. The need for power aware devices is not virtual anymore and this thesis will be focused in this subject.

The purpose of this project is to investigate the effects of several power aware strategies while designing an energy and power aware microcontroller based on 8051 ISA (Instruction Set Architecture) without disregard to silicon area, needed functionalities and performance. This thesis is part of a larger project that consists on the porting and upgrading of an object oriented operating system to the designed microcontroller as well as the development of an IDE (Integrated Development Environment) able to synthesize the optimized operating system and microcontroller core according to the metrics specified by system designer [2].

In doing so, the main focus will be on different architectural solutions to reduce both dynamic and static power consumption, that will depend on the chosen EDA (Electrical Design Automation) tools and the process technology itself. For instance, CMOS (Complementary Metal-Oxide-Semiconductor) processes were widely adopted and have essentially replaced nMOS (n channel mosfet) and bipolar processes for nearly all digital logic applications, mainly due to the very little energy used each time a CMOS transistor switch and negligible power dissipated when the circuit is not switching. However, power consumption becomes a major design consideration again due to the enormous number of transistors switching at very high speed rates on today’s ICs with millions or billions of transistors. Moreover, as transistors have become so small, they cease to turn completely OFF. Small amounts of current leaking through each transistor lead to higher power consumption when multiplied by millions of transistors on a chip. So, effects that were relatively minor in micron processes, such as transistor leakage, variations in characteristics of adjacent transistors, and wire resistance become crucial in nanometer processes.

Among the existing approaches, the following will be explored: (1) state encoding to reduce the switching activity by shortening the hamming distance between subsequent executed instructions; (2) clock gating to disconnect the flip flops clock from the clock tree and reducing power both from the flip flops and the clock tree; (3) power gating to shut down the power at non necessary blocks to reduce the leakage power; (4) asynchronous core to reduce both the clock skew problem and the clock tree which normally requires a very large silicon area with the associated increases in the power dissipation and limits the microcontroller speed; (5) a dynamic voltage and frequency scaling algorithm to adjust CPU core voltage and frequency on the fly according to the processing load.

The above techniques will be applied at the HDL (Hardware Description Language) programming level by the use of generative programming techniques, allowing for a high level control and better customization of the needed features built-in the designed CPU core [3] [4].

In order to verify the results, several benchmarks related to the specific application domain will be run on the synthesized CPU core using several EDA tools.

Keywords: embedded systems, microcontroller, 8051, low power, power-aware, state encoding,

clock gating, DVFS, verilog, HDL, generative programming

ix

Índice AGRADECIMENTOS ........................................................................................................... III

RESUMO ............................................................................................................................ V

ABSTRACT ....................................................................................................................... VII

INTRODUÇÃO .................................................................................................................... 1

Estado da Arte .................................................................................................... 2 1.1.

Aplicações e microcontroladores low power .................................................. 2 1.1.1.

Distinção Entre Potência e Energia ............................................................... 3 1.1.2.

Fontes de dissipação de energia .................................................................. 4 1.1.3.

Técnicas low power ...................................................................................... 8 1.1.4.

Microcontroladores low-power .................................................................... 15 1.1.5.

Motivação e contributo para uma nova metodologia low-power ......................... 17 1.2.

ESPECIFICAÇÕES DO LP805X ......................................................................................... 21

Trabalho Preliminar - arquitetura do mcs-51...................................................... 21 2.1.

ISA 8051 .......................................................................................................... 22 2.2.

Registos genéricos acessíveis ao programador............................................ 22 2.2.1.

Layout da Memória .................................................................................... 23 2.2.2.

Memória Interna de Dados ......................................................................... 24 2.2.3.

Memória Externa de Dados ........................................................................ 25 2.2.4.

Modos de endereçamento .......................................................................... 26 2.2.5.

Tipos de instrução ...................................................................................... 28 2.2.6.

Formato das Instruções .............................................................................. 32 2.2.7.

Características propostas para o LP805X .......................................................... 33 2.3.

COMPONENTES DO SISTEMA ......................................................................................... 35

Diagrama de Blocos do Sistema ....................................................................... 35 3.1.

x

Unidade de Processamento Central .................................................................. 36 3.2.

Unidade de Controlo ......................................................................................... 37 3.3.

Detalhes de implementação ....................................................................... 38 3.3.1.

Decoder ............................................................................................................ 42 3.4.

Detalhes de Implementação ....................................................................... 43 3.4.1.

Interface de Memória ........................................................................................ 44 3.5.


Subsistema ROM (Read Only Memory) ............................................................. 50 3.6.


Memória Interna de Dados ................................................................................ 53 3.7.


Unidade Lógica e Aritmética ............................................................................. 57 3.8.


Periféricos ......................................................................................................... 64 3.9.

Gerador de Números Aleatórios .................................................................. 65 3.9.1.

Criptografia AES ......................................................................................... 67 3.9.2.

Watchdog Timer ......................................................................................... 69 3.9.3.

Controlo de Potência .................................................................................. 71 3.9.4.

Suporte Escalonador Power Aware ............................................................. 81 3.9.5.

Suporte para Múltiplas Frequências .............................................................. 84 3.10.

TESTES E RESULTADOS .................................................................................................. 91

Verificação da ISA ............................................................................................. 92 4.1.

Recursos Utilizados ........................................................................................... 93 4.2.

Dissipação de Potência ..................................................................................... 94 4.3.

Co-Design com o Sistema Operativo .................................................................. 98 4.4.

CONCLUSÃO ................................................................................................................. 101

xi

Resultados, Limitações e Trabalho Futuro ....................................................... 101 5.1.

BIBLIOGRAFIA ................................................................................................................ 117

xiii

Lista de Abreviaturas

ALU Unidade lógica e aritmética, 38, 41, 56, 57, 58, 59, 60, 61, 62, 63, 64, 95

ASIC Application Specific Integrated Circuit, 8, 14, 46, 61, 64, 71, 72, 74, 75, 78, 79, 102

CMOS Complementary Metal-Oxide Semiconductor, v, vii, 4, 6, 7

CPU Central Processing Unit, vii, 22, 30, 31, 36, 38, 47, 50, 69, 70, 88, 89

DMA Acesso de memória direto, 47

DPTR Data Pointer, 22, 26, 27, 56, 58

DVFS Dynamic Voltage and Frequency Scaling, v, vii, 11

EDA Electronic Design Automation, v, vii, 16, 79, 101

EXE Execute, 16

FIFO First In First Out, 12, 85, 86, 88

FPGA Field Programmable Gate Array, 8, 14, 46, 52, 53, 54, 59, 61, 62, 64, 71, 72, 74, 75, 78, 79,

80, 91, 95, 96 FSM

Finite State Machine, 38 HDL

Hardware Description Language, v, vii, 16, 17, 19 IDE

Integrated Development Environment, v, vii, 19, 79, 91, 94 IP

Intellectual Property, 16, 17 ISA

Instruction Set Architecture, v, vii, 16, 19, 21, 22, 24, 26, 33, 35, 53, 55, 57, 58, 92 MMIO

Memory-mapped I/O, 35 NOP

No OPeration, 33, 39, 59 PC

Program Counter, 27, 28, 31, 32, 58 PSW

Program Status Word, 22, 23, 29, 41, 55, 56, 59 RAM

Random Access Memory, 14, 24, 30, 33, 50, 53 RAW

xiv

Read After Write, 40 RFID

Radio Frequency Identification, 1 RMW

read-modify-write, 41 ROM

Read Only Memory, 24, 30, 50, 51, 52, 91, 92, 93, 107 RTL

Register Transfer Layer, 38, 41, 42, 52, 54, 62, 69, 75, 76, 85, 91, 94, 102 SFR

Special Function Register, 22, 23, 25, 33, 36, 39, 40, 41, 49, 56, 57, 64, 65, 66, 67, 70, 76, 82, 83, 85, 88, 89, 103, 104, 105

SIP System in Package, 17

SoC System on Chip, 2, 4

SP Stack Pointer, 22, 40

xv

Índice de Figuras

Figura 1 – distinção entre potência e energia ..................................................................... 4

Figura 2 - potência dinâmica .............................................................................................. 5

Figura 3 - corrente de curto-circuito .................................................................................... 6

Figura 4 - potência estática num circuito CMOS ................................................................. 7

Figura 5 - técnicas de low-power......................................................................................... 9

Figura 6 - otimização de potência ..................................................................................... 10

Figura 7 - multi voltage and frequency scaling (retirado de [12]) ...................................... 12

Figura 8 - level shifter [12] ............................................................................................... 13

Figura 9 - bibliotecas multi-threshold ................................................................................ 14

Figura 10 - powergating com multi-vdd (retirado de [12]) ................................................. 15

Figura 11 – visão global no desenvolvimento de aplicações.............................................. 18

Figura 12 - registos do 8051 (retirada de [26]) ................................................................ 22

Figura 13 - registo PSW .................................................................................................... 23

Figura 14 - distribuição da memória 8051 ....................................................................... 24

Figura 15 – diagrama de blocos abstrato 805X ................................................................ 36

Figura 16 – datapath do pipeline de dois estágios ............................................................ 37

Figura 17 - RTL da unidade de controlo ........................................................................... 38

Figura 18 - diagrama de estados ST_STATE ..................................................................... 39

Figura 19 - simulação pipeline mov a,sp .......................................................................... 40

Figura 20 - imagem de place and route ............................................................................ 42

Figura 21 - exemplo uso de casez .................................................................................... 44

Figura 22 - seleção de endereços dados internos ............................................................. 45

Figura 23 - flags de acesso indireto .................................................................................. 46

Figura 24 - seleção da fonte de saída da memória interna de dados ................................ 47

Figura 25 - testbench para xram wishbone ....................................................................... 48

Figura 26 - comparação entre barramentos wishbone ...................................................... 49

Figura 27 – seleção do datapath para a ROM .................................................................. 49

Figura 28 - esquema de memória do LP805X .................................................................. 50

Figura 29 - código verilog accessos à ROM....................................................................... 52

Figura 30 - resolução de hazard sobre a leitura de RAM ................................................... 54

xvi

Figura 31 - leitura de RAM com resolução de hazard embutida ........................................ 54

Figura 32 - testbench do acesso indireto por registo ......................................................... 56

Figura 33 - leitura sobre ligação de três estados SFR ....................................................... 57

Figura 34 - estruturas da ALU .......................................................................................... 61

Figura 35 - estrutura híbrida da ALU ................................................................................ 61

Figura 36 - MUX 16:1 ALU ............................................................................................... 62

Figura 37 - multiplexadores de 4 e 2 entradas na ALU ..................................................... 63

Figura 38 - flag de seed limpa por hardware .................................................................... 66

Figura 39 - leitura do número aleatório de comprimento variável...................................... 67

Figura 40 - registo AESCON ............................................................................................. 68

Figura 41 - controlo aes e transferência de dados ............................................................ 69

Figura 42 - contagem watchdog com pré-escalar .............................................................. 70

Figura 43 - transição de relógio com glitch [29] .............................................................. 75

Figura 44 - transição de relógio sem glitch [29]............................................................... 75

Figura 45 – esquemático RTL de transição segura de relógio ........................................... 76

Figura 46 - seleção da fonte de relógio nova e antiga ....................................................... 77

Figura 47 - transição de relógio on-the-fly ......................................................................... 77

Figura 48 - exemplo de clock-gating ................................................................................. 78

Figura 49 - clock-gating recomendado pela Altera ............................................................. 78

Figura 50 - acordar microcontrolador com interrupção externa (retirado de [30]) ............. 80

Figura 51 - rotina de escolha de frequência power aware ................................................. 81

Figura 52 - suporte por hardware a escalonador power aware .......................................... 83

Figura 53 - código C++ para utilizar suporte a escalonador power aware por hardware .... 84

Figura 54 - diagrama de blocos de cross talk ................................................................... 85

Figura 55 - transferência de sinais entre domínios assíncronos (retirada de [31]) ............. 86

Figura 56 - lookup table para endereços de interface SFR assíncrona .............................. 87

Figura 57 - sinais de controlo para interface SFR assíncrona ............................................ 87

Figura 58 - fluxograma controlo SFR multifrequência ....................................................... 89

Figura 59 - suporte SFR assíncronos para periféricos múltipla frequência ......................... 90

Figura 60 - testbench de quase totalidade das instruções ................................................ 92

Figura 61 - estado da memória externa após teste ........................................................... 93

Figura 62 - recursos utilizados por microcontrolador numa configuração padrão .............. 93

xvii

Figura 63 - gasto de potência do microcontrolador a 12.2 MHz ....................................... 94

Figura 64 – nova medição do gasto de potência do microcontrolador a 12.2 MHz ........... 95

Figura 65 - medição do gasto de potência do microcontrolador a 12.2 MHz num chip de

dimensão de gama média ............................................................................................................ 96

Figura 66 - gráfico potência dissipada - frequência ........................................................... 96

Figura 67 - dissipação de potência em modo Idle ............................................................ 97

Figura 68 - dissipação de potência em modo sleep .......................................................... 97

Figura 69 - mudança de frequência pelo escalonador low-power e deteção de rotinas do

sistema operativo .......................................................................................................................... 98

Figura 70 - exemplo de teste de desempenho a função .................................................... 99

Figura 71 - registo de eventos do SO com reset por tmeout do watchdog ....................... 100

xix

Índice de Tabelas

Tabela 1 - classes de Memória 8051 clássico .................................................................. 24

Tabela 2 - modos de Endereçamento do 8051 ................................................................. 26

Tabela 3 - instruções aritméticas ...................................................................................... 29

Tabela 4 - instruções lógicas ............................................................................................ 29

Tabela 5 - instruções de transferência de dados ............................................................... 30

Tabela 6 - instruções booleanas ....................................................................................... 31

Tabela 7 - instruções de controlo ...................................................................................... 32

Tabela 8 - tabela de exemplos de instruções (x – don’t care) ............................................ 33

Tabela 9 - fetch de instruções da ROM ............................................................................. 51

Tabela 10 - opcodes de operação da ALU ........................................................................ 60

Tabela 11 - registos SFR para Números Aleatórios ........................................................... 66

Tabela 12 - registos de configuração AES ......................................................................... 67

Tabela 13 - registos SFR do Watchdog Timer.................................................................... 70

Tabela 14 - causas de Reset ............................................................................................ 71

Tabela 15 - recursos de Relógio entre Altera e Xilinx ......................................................... 73

Tabela 16 - contador binário para divisão de relógio ......................................................... 74

Tabela 17 - Implementação de modos de suspenção em várias tecnologias ..................... 79

Tabela 18 - registos SFR do módulo escalonador ............................................................. 82

xxi

Índice de Equações

Equação 1 - potência total num circuito CMOS .................................................................. 4

Equação 2 - energia despendida por cada transição de sinal ............................................. 5

Equação 3 - potência dinâmica variável ............................................................................. 5

Equação 4 - potência dinâmica fixa .................................................................................... 6

Equação 5 - potência estática ............................................................................................ 7

Equação 6 - aglomeração de registos ............................................................................... 43

1

Capítulo 1

Introdução

Os microcontroladores tornaram-se ubíquos estando presentes nos mais variados

equipamentos e dispositivos que podem: ser encontrados em casa; utilizados pela indústria;

utilizados em telecomunicações e em várias outras áreas que afetam a forma como vivemos o dia-

a-dia [1].

A eficiência energética não é tradicionalmente uma restrição para o correto funcionamento

dos equipamentos que se encontram permanentemente ligados a uma fonte de energia, como

muitos equipamentos industriais, ou pertencentes a aplicações cujo consumo do microcontrolador

represente uma pequena fração da potência total consumida pelo equipamento. No entanto,

exceder um determinado limite de potência pode ser fatal para um projeto, caso se traduza, por

exemplo, na mudança de um encapsulamento de plástico para um de cerâmica mais caro ou

mesmo numa fraca fiabilidade devido à excessiva densidade de potência [5].

Em equipamentos alimentados por baterias, que abrangem um dos segmentos com

crescimento mais rápido do mercado eletrónico, a eficiência energética tem um peso

preponderante sendo o consumo de energia uma restrição no caso de dispositivos autoalimentados

como por exemplos em dispositivos de RFID (Radio Frequency Identification) [6].

Para combater este problema, são utilizadas várias técnicas agressivas, ao longo da etapa

de desenho do sistema, desde o software que irá correr sobre o microcontrolador à

microarquitectura cuja implementação resultará no próprio microcontrolador. É então desenvolvido

um microcontrolador com métricas de baixo consumo e configurabilidade que permitem uma

coexistência simbiótica com o software para que ambos se adaptem mutuamente permitindo a

criação de um produto final otimizado em todas as frentes, visando em especial o baixo consumo

energético,

2

Estado da Arte 1.1.

São inúmeros os projetos e investigações atuais que adotam nos seus objetivos a redução

da dissipação de potência. Por outras palavras, a energia despendida pelos seus processadores

embebidos e a energia despendida pelo sistema/aplicação alvo.

O projeto SCALOPES [7] foca-se em tecnologias cross-domain e ferramentas de

desenvolvimento para arquiteturas multi-core. Os domínios de aplicação alvo são: infraestruturas de

comunicação, sistemas de vigilância, terminais móveis inteligentes e sistemas estacionários de

vídeo e entretenimento. Inseridos nos objetivos deste projeto estão metas como: redução de 30%

da potência consumida acompanhada por um aumento mínimo de 20% na performance de

sistemas embebidos multi-core; redução superior a 50% no consumo de energia para televisores e

monitores durante os próximos dois anos.

O projeto ASAM [8] centra-se num processo uniforme de síntese automática de

arquiteturas assim como mapeamento de aplicações para sistemas embebidos heterogéneos de

multiprocessador. Pretende então definir uma metodologia unificada de design, assim como,

ferramentas automáticas de prototipagem e síntese relacionadas. Este novo ambiente de design

permite uma rápida exploração através de algoritmos de alto nível e arquiteturas de design spaces.

Dadas as restrições do design moderno de SoC (System on Chip) são endereçadas a área, a

potência e a performance descendo de granularidade da exploração ao nível da microarquitectura

do sistema alvo.

Aplicações e microcontroladores low power 1.1.1.

A crescente procura por microcontroladores low-power é liderada por equipamentos

portáteis dependentes de bateria para sua alimentação incluindo [6] [1]:

1. Indústria: equipamentos de medição, de segurança e dispositivos RFID;

2. Comunicações: telemóveis, smartphones e consolas de jogos portáteis;

3. Eletrónica de consumo: equipamento médico portátil, câmaras digitais, leitores de música

portáteis e produtos RFID.

3

Inseridas dentro dos dispositivos autoalimentados, existem ainda aplicações em que os

dispositivos devem permanecer funcionais até uma dezena de anos, altura em que é feita a

substituição da bateria, como por exemplo, medidores de gás, medidores do nível do lixo,

dispositivos de tracking, etc…

Muitos destes dispositivos estão em constante upgrade de características numa batalha

por competitividade impulsionada pela constante procura de mercado por menores tempos de

resposta, melhores capacidades gráficas, maior capacidade de memória, entre outros [9].

Dado que o tamanho dos equipamentos tende também a diminuir, por consequência, o

tamanho dos dispositivos e baterias terão de diminuir. A redução da geometria ao nível dos

transístores no processo de fabrico resulta em mais perdas de energia estática no dispositivo final

[5]. Este facto aliado a baterias menores e de menor capacidade formam de certa forma um

contra-senso face às necessidades de baixo consumo.

Todos estes factos conjugados alimentam a procura de sistemas que operem em tensões

mais baixas e com menor consumo de potência. Todavia, esta procura deve ser aprofundada tendo

em vista o menor consumo de energia, senda esta distinção explicada de seguida.

Distinção Entre Potência e Energia 1.1.2.

Para dispositivos alimentados por bateria, a distinção entre potência e energia é crítica e a

sua confusão pode levar a tempos de vida mais curtos para os dispositivos. A potência pode ser

definida como a capacidade de realização de trabalho por um período de tempo e a energia como

o trabalho exercido ao longo do tempo. A potência é vista na Figura 1 como uma medida

instantânea sendo a energia a área debaixo do traçado, ou seja, o integral da potência ao longo do

tempo [5]. O termo de comparação deve então ser baseado na energia dissipada ou na potência

média consumida caso não seja possível partir o trabalho em intervalos de tempo.

4

Figura 1 – distinção entre potência e energia

A potência consumida é então dependente do uso que se estiver a dar ao dispositivo, se

por exemplo um dispositivo que está a enviar mensagens de rádio ou se está parcialmente

desligado, ou seja, em modo sleep. Todavia, deve-se ter em atenção que um consumo de potência

superior a dado momento não significa um consumo de energia superior para um dado tempo.

Neste sentido, não se pode afirmar que um dispositivo que envie mais mensagens de cada vez

gaste mais energia, tendo em vista o tempo expectável da bateria, pois pode ficar mais tempo em

modo de sleep.

Fontes de dissipação de energia 1.1.3.

A potência total consumida num SoC pode ser dividida em termos de potência dinâmica e

potência estática. A potência dinâmica é aquela que é consumida quando o dispositivo está ativo,

ou seja, quando há variação de valores nos sinais. A potência estática é aquela que é consumida

quando o dispositivo está ligado mas sem que haja qualquer alteração de sinais. Em dispositivos

de tecnologia CMOS, a potência estática é devida a fugas nos transístores [10].

O consumo de potência de um circuito CMOS digital pode ser expressado pela Equação 1:

( )

Equação 1 - potência total num circuito CMOS

Potência 1

0

2

4

6

8

10

1 2 3 4 5 6 7 8 9 10 11

Potência 1

Potência 2

µs

=mW

5

Onde se tem fclk como sendo a frequência de relógio, α é a atividade média, Vdd é a

tensão de alimentação e CL é a capacidade da carga. Nesta expressão identifica-se o primeiro

termo, entre parêntesis, como representando a potência dinâmica e o segundo representando a

potência estática.

A primeira e maior fonte de dissipação dinâmica é a potência de comutação, isto é, a

potência necessária para carregar ou descarregar a capacidade de saída numa gate, ilustrado na

Figura 2.

Figura 2 - potência dinâmica

A Equação 2 relaciona a energia dinâmica despendida por cada transição.

Equação 2 - energia despendida por cada transição de sinal

Onde CL é a capacidade da carga e Vdd a tensão de alimentação, pelo que se pode

descrever a potência dinâmica de comutação através da Equação 3.

Equação 3 - potência dinâmica variável

Onde α é a probabilidade de acontecer uma transição da saída e fCLK a frequência de

relógio do sistema. Desta expressão pode-se concluir que as perdas por comutação não dependem

6

do tamanho do transístor mas da atividade que acontece nos vários sinais e da sua respetiva

carga, ou seja, é dependente da variação no padrão de sinais acedidos em sequência.

Outra contribuição para as perdas dinâmicas são as correntes de curto-circuito que

ocorrem quando as redes de transístores nMOS e pMOS se encontram simultaneamente ligadas,

assim como a corrente necessária para carregar a capacidade interna da célula (evidenciado na

Figura 3).

Figura 3 - corrente de curto-circuito

Esta componente da potência dinâmica pode ser representada pela Equação 4.

( )

Equação 4 - potência dinâmica fixa

Esta corrente varia com a capacidade da carga, ou seja, com CL, pelo que para um valor

elevado de CL a corrente de curto-circuito é de aproximadamente zero. Para uma capacidade baixa

a corrente atinge os valores máximos [5]. Sendo esta componente correspondente a apenas 10%

da potência dinâmica total pode ser ignorada.

A potência estática é vista como o segundo termo da Equação 1 sendo que as quatro

principais fontes de correntes de fuga numa gate CMOS são como apontado em [5] (evidenciadas

graficamente na Figura 4):

1) Sub-threshold Leakage (ISUB): a corrente flui do drain até à source do transístor que opera

na região de fraca inversão. Esta fuga ocorre quando a gate CMOS não é completamente

7

desligada variando com as dimensões do transístor e com Vth (a tensão térmica que varia

com a temperatura);

2) Gate Leakage (IGATE): a corrente flui da gate, pelo óxido, até ao substrato devido gate oxide

tunneling e hot carrier injection. Apesar de inferior à corrente de sub-threshold, para

tamanhos da gate inferiores a 65nm esta fuga iguala a de sub-threshold;

3) Gate Induced Drain Leakage (IGIDI): a corrente flui do drain até ao substrato, induzida pelo

efeito de campo no drain do MOSFET causado por uma alta VDG;

4) Reverse Bias Junction Leakage (IREV): causada pela minoritária carrier drift e geração de

pares electron/holes nas zonas de depleção.

Figura 4 - potência estática num circuito CMOS

Equação 5 - potência estática

Esta potência estática (Equação 5) é consumida mesmo que o chip esteja quiscient, ou

seja, mesmo que determinadas áreas do chip não estejam a ser utilizadas. Deve ser tomada em

conta sempre que o chip ou bloco esteja alimentado.

A corrente de sub-threshold aumenta exponencialmente com a temperatura o que

complica o processo de design de sistemas low-power pelo que o sistema deve ser projetado tendo

em vista a especificidade da aplicação para a escolha de, por exemplo, um encapsulamento de

melhor qualidade de dissipação.

8

Técnicas low power 1.1.4.

Existem várias técnicas e metodologias low-power que permitem mitigar as diversas perdas

de energia descritas anteriormente. Seguindo um design low-power procura-se então reduzir tanto

as perdas de energia dinâmicas como estáticas. Analisando cada uma das fontes de dissipação de

energia, saltam à vista alguns dos parâmetros que podem ser modificados por forma a consumir

menor potência. Porém, para uma análise mais rigorosa deve-se verificar a Equação 1.

Para diminuir a potência dinâmica proveniente da carga e descarga das capacidades das

interconexões pode-se reduzir a capacidade das mesmas assim como a variabilidade dos sinais

que percorrem estas ligações. A redução da frequência de relógio também origina redução

semelhante na potência dinâmica sendo que esta depende ainda do quadrado da tensão de

alimentação, parâmetro individual com maior influência na dissipação total. Relativamente às

correntes de curto-circuito entre os transístores pMOS e nMOS a redução da tensão de alimentação

e da corrente máxima permitida são as únicas alterações realizáveis.

Relativamente à dissipação estática de potência, sendo que a maior componente é devida

a fugas de sub-threshold podem ser modificadas as dimensões dos transístores assim como as

tensões de threshold. A temperatura também provoca um aumento mesurável nas correntes de

fuga pelo que um elevado workload poderá contribuir para uma maior dissipação de potência, pelo

que não deve ser ignorada pelo projetista. Apesar da redução da tensão de alimentação ser

benéfica na diminuição da dissipação dinâmica, quando aliada a uma redução da tensão de

threshold pode levar a um aumento das fugas e no limite a um incorreto funcionamento do

sistema ao nível dos transístores.

Tendo-se então estudado alguns dos parâmetros que ditam o consumo de potência são de

seguida apresentadas algumas técnicas padrão para low-power design na Figura 5.

A aplicabilidade destes métodos depende, é claro, da tecnologia alvo. Por outras palavras,

a implementação do design em tecnologia ASIC (Application Specific Integrated Circuit) pode diferir

das suas homólogas em FPGA (Field Programmable Gate Array), sendo no pior dos casos

impraticável em certas arquiteturas FPGA. Estas técnicas podem também ser aplicadas

conjuntamente com uma estratégia power-aware que procura reduzir a potência consumida sem

degradar significativamente a performance. É então evidente que se torna altamente dependente

das especificidades de cada sistema.

9

Figura 5 - técnicas de low-power

1.1.4.1. Clock-Gating

Em muitos casos, a atividade do relógio (clock) associada a atividades desnecessárias nas

portas lógicas dos vários elementos do sistema provoca perdas de energia que podem ser evitadas

ou mitigadas utilizando a técnica de clock-gating.

O clock-gating permite reduzir o consumo de potência dinâmica desligando a árvore de

relógio de componentes do sistema sempre que as suas ligações de saída não sejam necessárias

ou se utilizadas fornecendo clocks mais lentos para determinadas atividades não críticas.

Reduz-se então a potência nas próprias árvores de relógio quando deixam de transitar a

frequências elevadas, assim como nos próprios elementos do sistema que são parados e respetivos

fan-outs.

No caso de um microcontrolador, por exemplo, pode-se utilizar este método para entrar

num modo standby, desativando toda a atividade do sistema enquanto se espera por determinado

evento, como por exemplo, uma interrupção externa.

Apesar das várias vantagens, o clock-gating traz complicações a nível da análise temporal

do circuito devido ao clock skew que induz nas linhas onde atua. Por outras palavras, são criados

novos domínios de clock que criam dificuldades acrescidas ao projetista, nomeadamente o clock

mét

od

os

pad

rão

Lo

w P

ow

er Clock Gating

Gate Level Power Optimization

Multi-Voltage

Multi-Threshold

Power Gating

10

skew, onde existe um atraso entre as linhas de clock de flip flops adjacentes levando a

propagações erróneas do sinal que podem resultar em falhas catastróficas [11].

Torna-se então necessária uma gestão do clock tendo em vista a salvaguarda do sistema

perante estas situações o que indubitavelmente aumenta a complexidade do sistema, podendo

mesmo comprometer a premissa inicial de redução da potência/energia.

1.1.4.2. Gate Level Power Optimization

A técnica de Gate Level Power Optimization permite fazer tanto o remapeamento das

entradas nas portas lógicas de múltiplas entradas como o remapeamento das próprias portas

lógicas por forma a otimizar a ligação física e lógica reduzindo a potência dinâmica.

Por exemplo, para o caso em que a saída de uma gate AND ligada a uma NOR por uma

ligação com uma alta atividade de comutação pode-se remapear as duas gates para uma AND-OR

seguida de um inversor. Desta forma a alta atividade passa a existir internamente à célula. A alta

atividade passa então a ocorrer numa ligação com capacidade inferior pelo que assim se reduz a

potência dinâmica (ver Figura 6).

Figura 6 - otimização de potência

Outro caso é para uma porta lógica de múltiplas entradas, como uma AND, em que a

capacidade das entradas da gate difere para cada entrada pelo que se pode fazer o remapeamento

das linhas de alta atividade para as entradas com a menor capacidade reduzindo também a

potência dinâmica.

Através do cell sizing 1, é possível aumentar ou diminuir a capacidade de condução (drive)

de uma determinada célula utilizando uma estratégia power-aware em que se aumenta a

capacidade de drive apenas para os caminhos críticos [5].

1 Estratégia de compromissos entre o tamanho dos transístores e uma outra métrica designada

11

Podem ainda ser inseridos buffers nas ligações mais extensas ao invés de aumentar a

capacidade de drive da gate pelo que pode também ser uma forma de reduzir a potência.

1.1.4.3. Multi Voltage and Frequency Scaling

Tal como visto na Equação 3 - potência dinâmica variável, a potência dinâmica é

diretamente proporcional à frequência e ao quadrado da tensão de alimentação, pelo que esta

metodologia passa por utilizar frequências e tensões diferentes para diferentes blocos do sistema.

Todavia, uma tensão de alimentação inferior provoca também um atraso adicional na transmissão

dos sinais.

Existem vários métodos relacionados com estes fatores, sendo que:

Static Voltage Scaling (SVS): aos vários blocos ou subsistemas, são dadas tensões de

alimentação diferentes, porém fixas;

Multi-Level Voltage Scaling (MVS): cada bloco ou subsistema pode ser alimentado entre

dois ou mais níveis de tensão, no entanto, estes níveis são fixos e discretos;

Dynamic Voltage and Frequency Scaling (DVFS): uma extensão do MVS onde um número

mais elevado de diferentes níveis de tensão e frequência são dinamicamente modificados

de acordo com a workload do sistema;

Adaptive Voltage Scaling (AVS): uma extensão do DVFS onde uma malha fechada de

controlo é utilizada para ajustar a tensão.

12

Figura 7 - multi voltage and frequency scaling (retirado de [12])

Na Figura 7 destacam-se possíveis implementações desta metodologia em que diferentes

blocos são alimentados a diferentes tensões de alimentação. O ajuste on-the-fly destas tensões

para uma adaptação ao workload do sistema requer todavia reguladores de tensão assim como de

geradores de frequência para o caso dos diferentes domínios de frequência.

É ainda necessário ter em conta alguns desafios aquando da aplicação destas

metodologias que se podem tornar num entrave para a implementação física das mesmas:

Crossing clock: para passar sinais entre dois domínios de clock diferentes é necessário um

subsistema capaz de receber dois clocks diferentes e minimizando a existência de meta

estabilidade, como por exemplo, uma estrutura FIFO (First In First Out). Este assunto não

é trivial podendo causar problemas indetetáveis caso a análise deste domínio se revele

incompleta;

Level Shifters: sinais entre blocos ou subsistemas que utilizem diferentes tensões

necessitam de um buffer que transforme a tensão de um nível para outro (Figura 8);

Characterization and Static timing analysis: com um único valor de tensão para o chip, a

análise temporal (timing analysis) pode ser feita num único ponto de desempenho; com

múltiplos blocos correndo a várias tensões e com bibliotecas (coleções de funções lógicas

ao nível do transístor com parâmetros fixos ou variáveis) que podem não caracterizar a

tensão correta, a timing analysis torna-se muito mais complexa;

Floor planning, power planning, grids: múltiplos domínios de tensão requerem mais cuidado

e detalhe no floorplanning tornando as power grids mais complexas;

13

Figura 8 - level shifter [12]

Board level issues: são necessários reguladores de tensão e geradores de clock adicionais

dentro ou fora do chip;

Power up and power down sequencing: diferentes domínios de tensão requerem uma

estratégia de power on e power off bem definida que assegure sempre o funcionamento

correto.

1.1.4.4. Multi-threshold

À medida que as dimensões dos transístores se reduzem, o uso de bibliotecas com

múltiplas tensões de threshold (VT) torna-se uma forma de reduzir as correntes de fuga. Como se

pode verificar pela Figura 9, as fugas diminuem com o aumento da tensão de threshold, no

entanto, com o aumento da tensão de threshold também se verifica um aumento no atraso dos

sinais nas gates.

A técnica de multi-threshold consiste então em utilizar vários níveis de threshold de acordo

com as métricas desejadas para obter uma solução ótima.

14

Figura 9 - bibliotecas multi-threshold

1.1.4.5. Power Gating

A forma mais natural de reduzir a dissipação de potência estática, para os subsistemas

que estejam em modo standby, é desligar a tensão de alimentação dos mesmos. Para

implementar o power gating podem ser utilizadas massas virtuais ou tensões de alimentações

virtuais que podem ser desligadas com um sinal de sleep. Em ASIC é usualmente utilizado um

nMOS devido à sua baixa resistência de passagem à corrente. Para reduzir as fugas, a tensão de

threshold deste transístor deve ser alta o suficiente. Para FPGA, apesar de ser limitativo o power-

gating é suportado possibilitando desligar as ligações de PLLs, DCMs, blocos de RAM (Random

Access Memory) não utilizados, entre outros. Esta capacidade é todavia dependente de cada

arquitetura FPGA.

O mesmo interruptor de sleep pode ser compartilhado por diversos subsistemas para

reduzir o impacto desta técnica sobre a área de silício, pelo que se pode escolher a granularidade

desejada tendo em atenção os impactos na área de silício.

Este é um método muito efetivo de reduzir o consumo de potência estática, no entanto,

requer que se lidem com alguns desafios para se obter uma implementação ótima, tais como:

Requer diferentes níveis para a tensão de threshold;

0

10

20

30

40

50

60

70

80

90

100

% Leakage

Delay

LVt SVt HVt

15

Transístores de maior tamanho têm menor resistência, porém ao utilizar transístores de

sleep maiores aumenta-se a área de silício ocupada;

Em circuitos sequenciais é necessária uma forma de armazenar e restaurar o estado do

circuito devido à perda de memória com a perda de alimentação.

A Figura 10 ilustra uma possível implementação do método de power-gating aliado ao

método de multi-vdd. Existem três blocos isolados e dois diferentes domínios de tensão (0,7V e

0,9V) sendo que um dos blocos se encontra parcialmente desligado recorrendo ao power-gating.

Figura 10 - powergating com multi-vdd (retirado de [12])

Microcontroladores low-power 1.1.5.

Atualmente existe uma vasta gama de famílias microcontroladores low-power operando em

gamas desde 1.8V a 5V e com consumos reduzidos, na ordem dos micros amperes, dependendo

obviamente do modo de operação e da carga do sistema.

Sendo esta necessidade de low-power um must-have é difícil destacar uma implementação

em particular pois, todos estes microcontroladores são desenhados e implementados pensando no

low-power pelo que são utilizadas várias técnicas e metodologias para diminuir o consumo de

potência [13] [14] [15]. Por exemplo, a Silabs afirma que a sua série F9xx de microcontroladores

da família 8051 tem o menor consumo de corrente no mercado, em modo ativo de operação.

Afirma também ter o menor consumo de corrente em modo sleep, muito utilizado em aplicações

alimentadas por baterias.

16

Para além das várias versões comerciais atualmente disponíveis encontram-se ainda várias

propostas académicas para implementações low-power.

Em [16], é apresentado um core de 8051 low-energy e low-voltage utilizando lógica

assíncrona baseada em 0,35µm. O microcontrolador é também dividido num pipeline de 2

estágios quase totalmente independentes um do outro e desprovido de algoritmos de predição, o

que aumentaria a área de silício ocupada e por conseguinte a potência dissipada.

Em [17], é utilizada uma estrutura assíncrona de pipeline adaptativo que permite avançar

estágios redundantes combinando-os com os estágios vazios vizinhos. Para reduzir a dissipação de

potência assim como para aumentar o desempenho, é feito o controlo de multilooping para

instruções de multi-ciclo, predições de salto para saltos incondicionais e single threading no estágio

EXE (execute).

Em [18], é proposto o design de um microcontrolador 8051 com interface para memória

externa comercial. O core assíncrono é implementado utilizando o protocolo dual-rail four-phase. A

ISA do 8051 não é completamente suportada, nomeadamente, note-se a falta de operações de

multiplicação e divisão.

Os IP (intellectual property) cores são blocos de lógica ou dados utilizados para configurar

FPGAs ou ASICs tendo em vista um produto [19]. O uso progressivo de IP cores na indústria de

EDA pode ser atribuído ao repetido uso de componentes previamente desenhados. Desta forma, a

reutilização de IPs reduz o tempo de desenvolvimento e, portanto, o tempo de colocação no

mercado (time-to-market) para um novo produto [20].

Os IP cores classificam-se numa das três categorias: hard cores, firm cores e soft cores

[19]. Os hard cores são implementações físicas do desenho IP. São, portanto, pouco portáveis e

flexíveis. Os firm-cores, também reconhecidos como semi-hard, são também hard-wired, ou seja,

definidos por um conjunto concreto e específico de ligações físicas, mas contendo características

configuráveis para várias aplicações. Os mais flexíveis de todos são os soft cores, que existem sob a

forma de netlist (uma lista de elementos lógicos e as interconexões associadas que compõem um

circuito integrado) ou sob a forma de código HDL (hardware description language).

Em [21], é apresentado um IP soft core parametrizável descrito em HDL, totalmente

síncrono por design e compatível com a ISA 8051. Porém, não foi desenhado tendo em vista o low-

power pelo que pode ser alterado tendo em vista essa métrica.

Os IP cores comerciais, tais como [21], [22] ou [23] são desenhados e implementados

tendo como principal métrica o desempenho. A forma como procuram reduzir a energia passa por

17

soluções arquiteturais apenas. Quando o core é fornecido sob forma de netlist, a parametrização

passa por utilizar diferentes netlists, ficando-se limitado a um conjunto de diferentes customizações

fixas. Quando é fornecido sob a forma de HDL, os cenários de customização passam a ser mais

alargados tendo-se no entanto de alterar determinadas porções de código.

Em [24], são apresentadas alterações a um IP core 8051 visando diminuir a variação dos

sinais lógicos e consequentemente diminuir a potência dinâmica. Foram utilizadas técnicas como

state-encoding e clock-gating para que a performance permanecesse inalterada. As alterações

foram apenas ao nível do HDL por forma a preservar a reusabilidade do IP e independência da

tecnologia alvo.

Motivação e contributo para uma nova 1.2.

metodologia low-power

As diferentes áreas de aplicação impõem regras específicas, como por exemplo, o baixo

consumo, a rapidez de processamento percetível pelo utilizador, a latência e o throughput. Como

tal, para cada aplicação em particular, seria uma mais valia determinar quais as métricas

desejadas e quais os recursos seriam necessárias para atingir os objectivos.

Neste sentido, os microcontroladores SIP (System in Package) disponíveis na indústria não

são obviamente uma opção pois são não customizáveis.

Os IP cores, previamente apresentados neste capítulo, por sua vez, permitem a

customização, variando esta capacidade de acordo com a solução oferecida; porém ficam aquém

de ser considerados como uma solução ideal pois a customização fornecida é, na maioria dos

casos, limitada às netlists fornecidas. Podem não possuir certas características-chave para uma

aplicação em particular, como por exemplo, controladores para protocolo de comunicações pouco

utilizados ou proprietários e mesmo a otimização em termos de potência. Para além deste desafio

na escolha de um IP core, torna-se também mais limitativo o co-design pois será mais complicado

ou mesmo impossível a troca de componentes integrantes do sistema que o IP core não forneça,

podendo no limite levar à troca de um core por outro. Todas estas dificuldades aumentam o tempo

de desenvolvimento e consequentemente o time-to-market.

18

Atualmente as metodologias low-power e power-aware são amplamente utilizadas sendo

críticas em aplicações/sistemas portáteis para se obter o mínimo consumo possível. Porém, estes

esforços são amplamente direcionados para plataforma de hardware descurando os restantes

componentes do sistema. Esta estratégia, sendo capaz de obter cabalmente otimizações a baixo

nível, torna-se todavia insuficiente quando os restantes componentes do sistema, nomeadamente

no software, não são capazes de beneficiar e de se ajustar aos recursos e funcionalidades que o

hardware permite.

Propõe-se então uma nova metodologia que visa otimizar todo o sistema de uma forma

transversal, com especial incidência no ambiente de desenvolvimento, sistema operativo, e

microcontrolador alvo.

Figura 11 – visão global no desenvolvimento de aplicações

Tal como se pode verificar na Figura 11 (através das roda dentadas), o movimento de cada

um dos blocos do sistema provoca a movimentação dos restantes, ou seja, existe uma

interdependência entre os blocos onde a ação de cada um provoca repercussões nos restantes. A

não sincronização entre os elementos provocará desperdício de energia e perda de performance

pelo que é necessário uma filosofia integradora entre todos os subsistemas. Para que se defina um

determinado conjunto de características da arquitetura do sistema como um todo, é necessário

que exista uma parametrização comum entre o sistema operativo e o microcontrolador. No

entanto, dada a diferente ordem de natureza entre os mesmos (software e hardware) é necessário

uma ferramenta de modelação que forneça elevado e ajustável nível de abstração para gerir o

8051

SO3

IDE

19

sistema a alto nível simplificando a compreensão, manutenção e extensão do mesmo. Para lidar

com as incompatibilidades geradas pela heterogeneidade semântica e estrutural das diferentes

camadas, é definida uma ontologia que rege a interoperabilidade e a organização da informação

entre as camadas, permitindo uma compreensão mútua entre o sistema operativo e o

microcontrolador quando auxiliado pela IDE [25].

Desta forma, no ambiente de desenvolvimento passa a ser possível customizar os sistemas

adjacentes, ou seja, o sistema operativo e o microcontrolador alvo. De outra forma, a título de

exemplo, mesmo com a utilização de um microcontrolador com baixo consumo de energia o

sistema pode tornar-se ineficiente ou mesmo consumir mais energia do que consumiria caso o

sistema operativo tomasse proveito das características do microcontrolador. Do mesmo modo, é

necessário especificar todas as partes constituintes do sistema, pois determinados periféricos

podem não necessitar de ter um desempenho elevado podendo mesmo não fazer sequer parte dos

requisitos da aplicação, traduzindo-se obviamente num consumo desnecessário de energia.

O trabalho desta dissertação foca-se no estudo e aplicabilidade das diversas técnicas de

redução do consumo de potência ao nível das características microarquitecturais do processador

alvo. Em adição, procurar-se-á sempre uma otimização independente da tecnologia alvo, facilitando

assim a sua aplicação de acordo com as configurações do ambiente de desenvolvimento.

Serão também equacionadas formas de controlar estática e dinamicamente as

funcionalidades do sistema através da expansão da ISA do 8051 e da customização do core e

periféricos do microcontrolador. A customização será gerida através da aplicação de técnicas de

programação generativa baseadas em regras e artefactos sintáticos e concretos que permitem a

modelação e geração automática de código. Este conceito será aplicado tanto no código do

sistema operativo como no do microcontrolador. Desta forma será possível gerir a mais facilmente

a complexidade do código HDL permitindo uma ligação concreta com os elementos de mais alto

nível.

21

Capítulo 2

Especificações do LP805X

Estudadas as técnicas mais utilizadas na redução do consumo de energia de sistemas

lógicos digitais, torna-se necessário recuar um passo antes de proceder à sua implementação num

microcontrolador da família mcs-51. Ou seja, o microcontrolador deve ser desenhado/redesenhado

de forma a se poder tirar partido das técnicas de redução de energia estudadas. De outra forma,

uma implementação inapropriada resultaria num overhead (inerente à glue-logic necessária a essa

mesma adaptação) demasiado acentuado que poderia colocar em causa a redução de energia.

Assim sendo, neste capítulo será apresentada a arquitetura da família mcs-51 sendo

propostas as características essenciais a reter pelo microcontrolador que resulta desta dissertação,

denominado de LP805X.

Trabalho Preliminar - arquitetura do mcs-51 2.1.

Um microprocessador comporta um conjunto limitado de instruções em linguagem

máquina assim como um conjunto de recursos internos que se encarrega de gerir estas mesmas

instruções. Este conjunto é normalmente designado por ISA (Instruction Set Architecture). A ISA

representa então a ligação entre a arquitetura do processador e o ambiente de programação

fornecido ao programador. Entre outros, devem conter o conjunto de instruções, arquitetura de

memória, modos de endereçamento e todos registos visíveis ao programador.

A microarquitectura é a forma como a ISA é implementada num processador. Neste

sentido, uma ISA pode ser implementada através de diferentes microarquitecturas. Os detalhes de

implementação podem variar devido a diferentes objetivos, a diferentes tecnologias ou mesmo

devido a conflitos de direitos de autor. A título de exemplo, a Intel Pentium e a AMD Athlon

implementam versões idênticas do instruction set x86 tendo designs internos completamente

diferentes.

No contexto desta dissertação, não só na tentativa de suporte de um leque de tecnologias

alvo mas também no fornecimento de uma variedade de opções de suporte ao ambiente de

22

desenvolvimento, poderão existir várias microarquitecturas de acordo com os parâmetros desejados

pelo projetista da aplicação alvo.

ISA 8051 2.2.

Registos genéricos acessíveis ao programador 2.2.1.

O 8051 clássico tem 4 bancos de registos contendo cada banco 8 registos. Estes registos

são mapeados na área de memória interna de dados, designada DATA, abrangendo os endereços

de 0 a 0x1F. Para além destes, existem ainda o registo A (acumulador) e o registo B sendo ambos

de 8 bits, o registo DPTR (data pointer) que é de 16 bits sendo utilizado para endereçar memória

externa de dados e de código. Estes registos, assim como os registos adicionais que possam existir

em complemento, estão mapeados numa zona de memória denominada de espaço SFR (Special

Function Register).

Figura 12 - registos do 8051 (retirada de [26])

O registo PSW (Program Status Word) contém bits de estado que refletem o estado atual

do CPU (Central Processing Unit).

A versão clássica do PSW contém as flags de carry, carry auxiliar (para operações em BCD

(binary coded decimal)), seleção do banco de registos r0-r7 a utilizar, overflow e paridade sobrando

apenas um bit para propósito geral. Por forma a configurar possíveis novos estados do CPU

resultantes de modificações ao microprocessador é utilizado ainda um registo PSW1 que será

reconhecido pelo CPU e onde estão as flags adicionais. O registo SP (Stack Pointer) é utilizado

como apontador para a pilha.

23

Figura 13 - registo PSW

No espaço dos SFR existem ainda outros registos que, não estando todavia diretamente

relacionados com o microprocessador, são responsáveis pela configuração e controlo de diversos

blocos do microcontrolador. Alguns destes registos são considerados mais à frente no capítulo 3.9.

Layout da Memória 2.2.2.

A tabela 1 representa as classes de memória utilizadas para programar a arquitetura

clássica do 8051. Estas classes de memória estão disponíveis quando programando ao nível do

assembly ou mesmo ao nível de linguagens C/C++ dependendo da flexibilidade fornecida pelo

compilador. Os prefixos de memória, tais como D: I: X: C:, são por norma utilizados por IDEs pois,

permitem que a classe de memória associada a um dado endereço seja facilmente identificável

promovendo a integração entre os ambientes de depuração e os seus respetivos utilizadores.

24

Tabela 1 - classes de Memória 8051 clássico

Classe de Memória Endereçamento Descrição

DATA D:00 – D:7F Endereçável diretamente na

RAM interna

BIT D:20 – D:2F Endereçável ao bit na

RAM interna através

instruções ao bit

IDATA I:00 – I:FF Endereçável indiretamente

na RAM interna utilizando

@R0 e @R1

XDATA X:0000 – X:FFFF 64 KB RAM acedidos pela

instrução MOVX

CODE C:0000 – C:FFFF 64 KB ROM para memória

de código e constantes

Para uma fácil compreensão da distribuição da memória e suas dimensões apresenta-se

na figura 3 um diagrama do mesmo.

Figura 14 - distribuição da memória 8051

Memória Interna de Dados 2.2.3.

A memória de dados interna é endereçável ao byte (tamanho da palavra do 8051) em todo

o seu conteúdo alongando-se até 256 bytes de R/W. Contém também uma área endereçável ao bit

que permite ao programador utilizar operações booleanas da ISA.

25

Do endereço 0 ao 31 encontram-se os 4 bancos de registos de 8 bits contendo os registos

genéricos r0-r7 apresentados anteriormente. Operações de escrita explícitas sobre estes endereços

levam todavia ao corrompimento do conteúdo dos registos r0-r7 correspondentes dado a que se

encontram mapeados nesta gama de endereços.

De seguida tem-se 128 bits que podem ser asserted, testados ou limpos através de uma

única instrução dispensando o overhead que traria a sua implementação em software sobre zonas

de memória endereçáveis apenas ao byte.

A memória imediatamente superior até ao endereço 127 é novamente endereçável apenas

ao byte sendo normalmente utilizada para armazenar variáveis. Estes endereços de 0 a 127 são

endereçáveis tanto por endereçamento direto ou indireto como se pode ver quando forem

apresentados todos os modos de endereçamento disponíveis. A memória na gama de endereços

de 128 a 255 é apenas endereçável indiretamente sendo normalmente utilizado como

armazenamento para a stack. Esta cresce em incremento estando limitada apenas à memória

interna, ou seja, a 256 bytes.

Ainda no limiar da memória interna existe um outro segmento endereçável ao byte desde o

endereço 128 a 255, ou seja, 128 bytes de memória. Esta zona de memória é designada por

espaço SFR e contém mapeados registos que controlam funcionalidades específicas do

microcontrolador tais como os portos de entrada/saída e o subsistema de interrupções.

Memória Externa de Dados 2.2.4.

Esta memória de dados é R/W e pode ser acedida através de acesso indireto utilizando

uma instrução especial para o efeito, de mnemónica MOVX.

Pode-se dividir em duas categorias: a memória externa interna (onchip) e a memória

externa externa (offchip); o espaço de memória permitido pela arquitetura mcs-51 é de até 64KB

sendo que três barramentos são disponibilizados para o efeito:

Barramento de endereços de 16 bits;

Barramento de dados de 8 bits;

Barramento de controlo de 3 bits.

Este espaço de memória pode não ser totalmente utilizado pelo que uma pequena gama

do endereçamento de dados externo pode ser utilizada para mapear periféricos, ou seja, permite

especificar uma segunda área de SFRs.

26

Modos de endereçamento 2.2.5.

Independentemente do tipo de ISA do microprocessador é necessário especificar a

representação e identificação dos endereços de memória para que o processador possa aceder aos

operandos (seja para leitura ou escrita). Para além de posições de memória também se

especificam constantes e registos.

Na tabela 2 apresentam-se os 9 diferentes modos de endereçamento utilizados no 8051.

Tabela 2 - modos de Endereçamento do 8051

Modo de endereçamento Exemplo

Endereçamento imediato MOV A,#55H

Endereçamento direto MOV A,050H

Endereçamento direto por registo MOV A,R7

Endereçamento indireto por registo MOV A,@R0

Endereçamento implícito PUSH ACC

Endereçamento indexado MOVC @A+DPTR

Endereçamento relativo SJMP loop

Endereçamento absoluto ACALL pid

Endereçamento longo LJMP isr7

O registo destino deve ser capaz de comportar o tamanho de dados especificados no

operando fonte.

Exemplos:

ADD A,#0xAB ; soma ao acumulador 171 em decimal

MOV DPTR,#0xAA55 ; move para o DPTR 0xAA55

O modo de endereçamento direto permite especificar o operando através do endereço de

memória real ou através de macros assembler (auxiliando o programador na escrita do código). É

então utilizando este modo que se acede aos SFRs utilizados para controlar o microcontrolador.

Exemplos:

ORL A,P2 ; faz um “ou” lógico entre acumulador e porto 2

MOV A, 0x87 ; move para A o conteúdo do endereço 0x87

27

O modo de endereçamento direto por registo promove a transferência de dados entre

registos. No evento da utilização de registos manipulados por bancos de registos, o número do

banco a utilizar deve ser especificado antes da instrução.

Exemplos:

MOV R7,A ; move para R7 o conteúdo de A

MOV A,R0 ; move para A o conteúdo de R0

O endereçamento indireto por registo utiliza um apontador que contém o endereço efetivo

do operando. Apenas os registos R0, R1 e DPTR podem ser utilizados. Os registos R0 e R1

permitem aceder a endereços de 8 bits sendo que o DPTR permite armazenar endereços de 16

bits. O registo DPTR é sobretudo utilizado para aceder a dados presentes na memória externa dado

a sua vasta gama de endereços.

Exemplos:

MOV A,@R0 ; move para A o conteúdo da posição de memória cujo

; endereço é formado pelo conteúdo de R0

MOVX @DPTR, A ; move A para o endereço dado pelo conteúdo de DPTR

O modo de endereçamento implícito não se especifica um operando pois tem-se sempre

associado um determinado registo ou pilha. Apesar de este modo de endereçamento não se aplicar

diretamente no 8051, as instruções PUSH e POP que usam o modo de endereçamento direto

especificam implicitamente o topo da pilha como sendo o outro operando.

Exemplos:

PUSH B ; incrementa apontador para pilha e coloca registo B na pilha

O modo de endereçamento por deslocamento, nomeadamente base por registo, é

especialmente útil quando se necessita aceder a dados de look-up tables. Neste modo,

especificam-se dois operandos onde um deles contém um endereço de memória e o outro o

deslocamento relativo ao endereço de memória. No 8051 ambos os operandos são implicitamente

especificados correspondendo ao acumulador e ao PC (Program Counter)/DPTR (Data Pointer) .

Exemplos:

MOVC A,@A+DPTR ; move para A o conteúdo da memória de instruções

; cujo endereço é formado pela soma entre A e DPTR

O modo endereçamento relativo é utilizado através de algumas instruções de salto, tal

como SJMP e saltos condicionais tais como JNZ. Estas instruções transferem o controlo de uma

28

parte do programa para outra. O operando fornecido pela instrução contém um offset que será

adicionado ao endereço da instrução atual por forma a gerar o endereço efetivo. Este destino

efetivo deve-se encontrar entre -128 e +127 bytes da instrução atual dado o comprimento de 8 bits

do offset.

Exemplos:

SJMP main ; salta para endereço de label main

JNZ loop ; se A diferente de zero salta por offset para loop

O modo de endereçamento absoluto associa as instruções ACALL e AJMP. Estas são

instruções de 2 bytes que especificam um endereço absoluto de 11 bits. Atendendo ao fato dos 5

bits mais significativos do PC (16 bits) não serem modificados, estas instruções permitem apenas

saltos dentro de páginas de 2K, onde a memória de código se encontra logicamente dividida em

32 páginas.

Exemplos:

ACALL sfr_config ; guarda PC na pilha e salta para sfr_config

O modo de endereçamento longo é utilizado através das instruções LCALL e LJMP. Estas

são instruções de 3 bytes em que os últimos 2 bytes especificam um endereço destino de 16 bits

para onde o programa salta. Desta forma é possível percorrer 64K de memória de código, ou seja,

todo espaço de instruções em muitas versões do 8051. Assim sendo, é possível saltar para uma

determinada localização qualquer que seja a localização onde o programa se encontrava

anteriormente.

Exemplos: LCALL timer_init ;

Tipos de instrução 2.2.6.

As instruções no 8051 encontram-se basicamente divididas em 5 grupos funcionais:

Instruções aritméticas;

Instruções lógicas;

Instruções de transferência de dados;

Instruções de variáveis booleanas;

Instruções de salto.

Quando se executam opções aritméticas (Tabela 3) o processador não tem conhecimento

especial sobre o formato dos dados envolvidos na operação (com ou sem sinal, BCD, ASCII, etc.).

29

As flags de estado no registo PSW devidamente atualizadas quando ocorrem determinadas

condições permitindo que o software do utilizador consiga gerir diferentes formatos de dados (carry,

overflow, etc.).

Tabela 3 - instruções aritméticas

Mnemónica Descrição Mnemónica Descrição

ADD A, Rn A = A + [Rn] INC A A = A + 1

ADD A, direto A = A + [direta2] INC Rn [Rn] = [Rn] + 1

ADD A, @Ri A = A + [@Ri3] INC direto [direto] = [direto] + 1

ADD A, #dados A = A + imediato INC @Ri [@Ri] = [@Ri] + 1

ADDC A, Rn A = A + [Rn] + CY DEC A A = A - 1

ADDC A, direto A = A + [direto] + CY DEC Rn [Rn] = [Rn] - 1

ADDC A, @Ri A = A + [@Ri] + CY DEC direto [direto] = [direto] - 1

ADDC A, #dados A = A + imm + CY DEC @Ri [@Ri] = [@Ri] - 1

SUBB A, Rn A = A - [Rn] - CY MUL AB Multiplica A & B

SUBB A, direto A = A - [direto] - CY DIV AB Divide A por B

SUBB A, @Ri A = A + [@Ri] - CY DA A Ajuste decimal de A

SUBB A, #dados A = A - imm - CY

As instruções lógicas utilizam-se para efetuar operações booleanas (AND, OR, XOR e NOT)

em bytes de dados ou mesmo bit a bit (Tabela 4). Outras operações consideradas lógicas podem

limpar o acumulador, rodar o acumulador ou mesmo trocar os nibbles4 do acumulador.

Tabela 4 - instruções lógicas


ANL A, Rn A = A & [Rn] XRL A, Rn A = A ^ [Rn]

ANL A, direto A = A & [direta] XRL A, direto A = A ^ [direta]

2 Endereço de memória direta

3 Endereço apontador por Ri

4 Sucessões de quatro bits

30

ANL A, @Ri A = A & [@Ri] XRL A, @Ri A = A ^ [@Ri]

ANL A, #dados A = A & imediato XRL A, #dados A = A ^ imediato

ANL direto, A [direto] = [direto] & A XRL direto, A [direto] = [direto] ^ A

ANL direto, #dados [direto] &= imediato XRL direto, #dados [direto] ^= imediato

ORL A, Rn A = A | [Rn] CLR A Limpa A

ORL A, direto A = A | [direta] CPL A Complementa A

ORL A, @Ri A = A | [@Ri] RL A Roda A à esquerda

com carry

ORL A, #dados A = A | imediato RLC A Roda A à esquerda

ORL direto, A [direto] = [direto] | A RR A Roda A à direita com

carry

ORL direto, #dados [direto] |= imediato RRC A Roda A à direita

SWAP A Troca nibbles

As instruções de transferência de dados são utilizadas para transferir dados de uma

localização para outra. A informação é então transferida para um dos registos do CPU sendo então

encaminhada para o endereço de destino. Para o 8051 pode-se ainda dividir em 3 grandes tipos

de transferência (Tabela 5): MOV destino, fonte; PUSH fonte, POP destino; XCH destino, fonte.

Estes tipos recorrem aos modos de endereçamento descritos anteriormente: imediato, direto por

registo, direto, indireto e por deslocamento. As instruções MOVX e MOVC podem também ser

utilizadas para aceder a endereços da RAM externa e ROM, respetivamente.

Tabela 5 - instruções de transferência de dados


MOV @Ri, direto [@Ri] = [direto] MOVX @DPTR, A Externa[@DPTR] = A

MOV @Ri, #dados [@Ri] = imediato PUSH direto Coloca na pilha

MOV DPTR, #dados16 [DPTR] = imediato POP direto Retira da pilha

MOVC A, @A+DPTR A = Código de

[@+DPTR]

XCH A, Rn A = [Rn], [Rn] = A

MOVC A, @A+PC A = Código de

[@A+PC]

XCH A, direto A = [direto],

[direto] = A

31

MOVX A, @Ri A = Dados de RAM

externa [@Ri]

XCH A, @Ri A = [@Rn],

[@Rn] = A

MOVX A, @DPR A = Dados de RAM

externa [@DPTR]

XCHD A, @Ri Troca nibbles

MOVX @Ri, A Externa[@Ri] = A

As instruções booleanas permitem efetuar operações de um só bit tais como limpar, ativar

ou complementar o bit. Estão também incluídas instruções de transferência e de salto condicional.

De notar que todos os acessos ao bit são através de endereçamento direto. A Tabela 6 identifica

estas mesmas instruções.

Tabela 6 - instruções booleanas


CLR C Limpa C ORL C, bit | bit com C

CLR bit Limpa bit direto ORL C, /bit | não bit com C

SETB C Ativa C MOV C, bit Move bit para C

SETB bit Ativa bit direto MOV bit, C Move C para bit

CPL C Complementa C JC rel Salta se C ativo

CPL bit Complementa direto JNC rel Salta se C limpo

ANL C, bit & bit com C JB bit, rel Salta se bit ativo

ANL C, /bit & não bit com C JNB bit, rel Salta se bit limpo

JBC bit, rel Salta e limpa

As instruções de controlo (Tabela 7) permitem alterar o fluxo de execução do programa

efetuando o fetch de uma posição de memória que pode não ser o endereço de memória

consecutivo. Desta forma, o valor do PC é alterado dependendo de outros parâmetros para além

do comprimento da instrução atual. Estes parâmetros permitem, para além de alterar o fluxo de

execução, o controlo do fluxo de execução do programa através do estado das flags do CPU

resultante da execução das instruções anteriores. Em adição, existe ainda uma classe especial de

instruções de controlo usadas na gestão de sub-rotinas e de interrupções. As instruções de

chamada à sub-rotina, normalmente salvaguardam na pilha o endereço da instrução seguinte

32

saltando de seguida para o endereço efetivo de salto. A instrução de retorno das sub-rotinas efetua

um POP do endereço armazenado previamente na pilha para o PC resultando no salto para a

instrução seguinte à instrução que gerou o salto.

Tabela 7 - instruções de controlo


ACALL addr11 Call em páginas de 2K JNZ rel Salta se A != 0

LCALL addr16 Call em páginas de 64K CJNE A, direto, rel

Compara e salta

se diferente

RET Retornar de call CJNE A, #dados, rel

RETI Retornar de interrupção CJNE Rn, #dados, rel

AJMP addr11 Salto em páginas de 2K CJNE @Ri, #dados, rel

LJMP addr16 Salto em páginas de 64K DJNZ Rn, rel Decrementa e salta se

diferente de 0 SJMP rel Salto com offset de 128 DJNZ direto, rel

JMP @A+DPTR Salto indireto NOP Não faz nada

JZ rel Salta de A = 0

Formato das Instruções 2.2.7.

As instruções são a forma de especificar as ações que devem ser levadas a cabo pela

unidade de controlo e circuito de dados do processador por forma a atingir o objetivo desejado

(operação). As mnemónicas assembly devem então ser traduzidas para um formato binário

denominado de linguagem máquina. É então representada por uma sequência de bits sendo

dividida em grupos que constituem cada instrução. Dentro de cada grupo (instrução) existem

subgrupos identificando o opcode da instrução a executar assim como os endereços dos

operandos associados à operação.

O formato de instruções da família mcs-51 não é regular, apresentando comprimento

variável e vários formatos de instrução. Como se pode verificar na Tabela 8, que representa

algumas instruções de formatos diferentes, o número de ciclos máquina por instrução é variável.

Cada ciclo máquina é composto por seis estágios demorando cada estágio dois períodos de

relógio. Todas as instruções e respetivos ciclos e formatos podem ser visualizados em anexos.

33

Tabela 8 - tabela de exemplos de instruções (x – don’t care)

Mnemónica Byte 0 Byte 1 Byte 2 Ciclos

NOP 00000000 X X 1

AJMP A10A9A800001 A7A6A5A4A3A2A1A0 X 2

LJMP 00000010 A15-A8 A7-A0 2

INC Rn 00001nnn X X 1

CPL bit 10110010 bit X 1

ORL addr, #val 01000011 direto imediato 2

Pode-se então afirmar que a instrução mais rápida a executar demora ainda assim doze

ciclos de relógio sendo que a mais lenta demora quarenta e oito ciclos de relógio.

Esta é provavelmente uma das maiores desvantagens do 8051 clássico da intel que

contribui para um gasto energético bastante significativo.

Características propostas para o LP805X 2.3.

Antes de entrar em detalhe sobre o mapa das possíveis formas que a ISA poderá tomar

(escolhida pelo projetista) é feita uma análise sobre características base a suportar pelo que a

microarquitectura deve ser criada ou adaptada de forma a ir ao encontro destas métricas.

Propõe-se então o seguinte:

O microprocessador deve ser compatível com a ISA base do 8051 pelo que deve ser capaz

de executar todas as instruções assim como ser possível de customizar de acordo com as

especificações desejadas pelo projetista;

Deve ser possível endereçar até 256 bytes de memória RAM (Random Access Memory)

interna de acordo com a ISA do 8051;

o Ter ainda a possibilidade de adicionar registos SFR de acordo com a necessidade.

Capacidade de suportar pelo menos 64k bytes de memória de instruções;

Capacidade de suportar pelo menos 64k bytes de memória externa de dados

interna/externa;

34

o Possibilidade de suportar um modelo híbrido em que se usam ambas as

memórias onchip e offchip.

Suportar pelo menos até 4 portos de entrada/saída sendo endereçáveis ao bit e que se

possam definir como portos de entrada ou saída de dados;

o Através de multiplexagem, determinados pinos podem ter várias funções

alternativas, como por exemplo, os pinos relativos a uma USART.

Suportar interrupções com diferentes níveis de prioridade programáveis;

o Adicionar suporte para que qualquer periférico possa ter a sua própria linha de

pedido de interrupção.

Suportar uma unidade de controlo de energia com capacidade de controlar estática e

dinamicamente várias regiões do microcontrolador;

Suporte de comunicação entre várias regiões do microcontrolador que se podem encontrar

a níveis de tensão e frequência diferentes;

Reduzir o número de ciclos de relógio necessários para cada instrução dado que se

encontram relacionados, em proporção direta, à potência dissipada.

35

Capítulo 3

Componentes do Sistema

Neste capítulo descreve-se o sistema proposto nesta dissertação de mestrado. Durante

toda a etapa de desenvolvimento, seguiu-se o princípio da modularidade, em que os componentes

de um dado sistema podem ser separados e recombinados, o que é sem dúvida indispensável no

desenvolvimento de um sistema reconfigurável. Desta forma, também se facilita a verificação das

especificações, em termos de desempenho e potência, das várias configurações possíveis do

sistema, dado que os vários módulos integrantes do sistema poderão ser desenvolvidos, testados

separadamente e posteriormente integrados.

Primeiramente será apresentado o diagrama de blocos do sistema com especial incidência

no microprocessador e nos seus blocos constituintes passando de seguida pela apresentação de

todos os periféricos do sistema.

Diagrama de Blocos do Sistema 3.1.

A Figura 15 evidencia um digrama de blocos, muito abstrato, do sistema. O CPU

desenvolvido liga-se à memória (interna/externa) de código e externa de dados através de

barramentos próprios, sendo independente do resto sistema. Isto permite com que as instruções

da ISA 8051 sejam testadas e verificadas independentemente do sistema.

Os periféricos podem-se dividir em três classes diferentes de acordo com a sua interação

com os restantes subsistemas. Na ISA 8051, o acesso aos periféricos é através de MMIO (Memory-

mapped I/O). Este é um método que utiliza o mesmo barramento de endereços para acesso à

memória e periféricos; por outras palavras, quer a memória quer os registos de controlo dos

periféricos encontram-se mapeados ou associados a um determinado endereço de memória.

Em concreto, o barramento de memória partilhado com os registos é o mesmo que

endereça a memória interna de dados.

36

Figura 15 – diagrama de blocos abstrato 805X

Apesar de existirem outros tipos de SFRs que não estejam diretamente associados a

periféricos, todos fazem parte de um único barramento SFR, que é também comum a todos os

tipos de periféricos. As três classes de periféricos dividem-se então em:

1. Periférico I/O cuja tarefa é converter sinais internos em externos e vice-versa;

2. Periférico sem qualquer interface externa, cuja única função é controlar sinais internos do

microcontrolador;

3. Periférico híbrido que resulta da junção entre as classes anteriores e que permite um maior

grau de funcionalidades.

O microcontrolador desenvolvido apresenta ainda uma outra distinção entre periféricos

sendo relevante apenas ao nível da tecnologia alvo em termos de desempenho e consumo,

mantendo-se a sua funcionalidade intáctil; será explicado mais adiante aquando da apresentação

dos periféricos.

Unidade de Processamento Central 3.2.

Esta unidade, mais conhecida pela sua sigla inglesa (CPU), é responsável pela execução

das instruções de um programa carregado na memória de código. O CPU é composto basicamente

pela unidade de controlo e o circuito de dados (datapath). O circuito de dados é que realmente

executa as operações de acordo com os sinais fornecidos pela unidade de controlo sendo

37

composto por registos e memórias, pela ALU que calcula as operações lógicas e aritméticas e

mecanismos de ligação, como por exemplo barramentos ou ligações ponto a ponto.

Por forma a combater os elevados gastos energéticos inerentes aos ciclos máquina do

8051 clássico, foi descartada a máquina de estados por este utilizada sendo desenhada uma

consideravelmente mais otimizada. Tal como foi referido anteriormente, e por forma a permitir uma

posterior extensão do sistema, é permitida alguma flexibilidade nos saltos entre estados, algo que

também não se encontrava no 8051 clássico.

Foi então arquitetado um pipiline de dois estágios que permite com que todas as

instruções, com exceção das instruções de salto, sejam resolvidas num único ciclo de relógio

(Figura 16).

Unidade de Controlo 3.3.

A unidade de controlo tem a função, como o próprio nome indica, de controlar a

sequência de atividades no microprocessador. Está então encarregue de encaminhar os dados

para as fontes e destinos corretos. Para isso necessita de monitorizar o estágio de execução das

instruções por forma a determinar corretamente quais os sinais de controlo que deve gerar.

A unidade de controlo deve então gerir o datapath de acordo com a instrução “atual” (os

diferentes tipos de instrução podem ser revistos em anexos). Esta gere simultaneamente os dois

estágios do pipeline embora não controlando todos os sinais na totalidade, relegando alguns sinais

Figura 16 – datapath do pipeline de dois estágios

38

de controlo, como a seleção de operandos da ALU, para outras pequenas unidades de controlo

(Figura 17). Desta forma, torna-se mais fácil corrigir ou até adicionar funcionalidades sem para tal

ter de alterar toda a unidade de controlo central.

Figura 17 - RTL da unidade de controlo

Detalhes de implementação 3.3.1.

A unidade de controlo central é implementada através de uma máquina de estados FSM

(Finite State Machine) [27] que toma partido da descodificação de instruções efetuada pelo

decoder (exemplificada avante). Existem então três estados de controlo (ST_STATE) em que o CPU

se pode encontrar: o estado ST_RESET de reset onde os vários registos internos do CPU (não

visíveis ao programador) são colocados nos seus valores predefinidos para um correto

funcionamento do CPU; o estado ST_WORK utilizado para as instruções que requeiram mais de 1

39

ciclo de relógio (apesar de este ser composto por mais do que uma iteração possível); o estado

ST_FIEI em que é efetuado o fetch da instrução e a escrita da execução da instrução anterior.

Figura 18 - diagrama de estados ST_STATE

Na Figura 18 pode-se visualizar o diagrama de estados para a máquina de estados

ST_STATE. Todos os estados podem passar para ST_RESET desde que assim se verifiquem as

condições necessárias para um reset (não representadas na figura para simplificar o desenho), tais

como uma transição positiva no pino externo de reset. O estado de ST_FIEI é utilizado para adquirir

e analisar a próxima instrução a ser executada. De acordo com o tipo de instrução a usar, a

máquina de estados saltará para um estado ST_WORK caso sejam necessários mais do que um

ciclo de relógio ou permanecerá em ST_FIEI sempre que seja possível executar a instrução num

único ciclo de relógio. Os estados designados de ST_WORK são então utilizados para conduzir as

micro-operações associadas a uma determinada instrução, como por exemplo, carregar um dado

de um determinado endereço da memória externa de dados e carregá-lo para o acumulador. Cada

um destes estados ST_WORK é auto decremental, ou seja, se a máquina de estado estiver no

estado ST_WORK_3, no próximo ciclo de relógio estará no estado ST_WORK_2.

Desta forma, é possível customizar as instruções através das micro-operações necessárias,

dando flexibilidade ao sistema para futuras funcionalidades (como por exemplo, operar sobre os

SFR de periféricos a frequências diferentes – Capítulo 3.10).

Apesar desta máquina de estados prever que possam ser necessárias várias micro-

operações, estas mesmas operações podem necessitar de ciclos de relógio adicionais para que

completem pelo que são utilizadas condições adicionais para que seja permitido um salto de

estado. Sendo assim, um estado apenas pode transitar quando existam hits no acesso à memória

de instruções e à memória de dados (notar que os SFR estão mapeados na memória de dados).

Perante estas condições, o output dos sinais da máquina de estados pode ainda ser ignorado ou

trazido para os seus valores por defeito através da máscara com o opcode da instrução alvo,

podendo-se simular micro-operações NOP (No OPeration) à espera de dados ou instruções válidas.

40

A máquina de estados ST_STATE, independentemente do estado encontra-se dividida em

duas partes; uma com saídas (sinais de controlo) combinacionais e a outra com saídas (também

sinais de controlo) sequenciais, ou seja, cujas saídas se ligam a flip flops. Desta forma e entre

outras, é por exemplo possível resolver operações que envolvam leituras à memória ou ao register

file (mapeado na memória interna de dados) num ciclo de relógio, sem necessidade de recorrer a

memórias assíncronas que são geralmente mais caras, consumindo lookup tables ao invés de

blocos de memória dedicados.

Na Figura 19 apresenta-se um recorte da simulação dos acontecimentos na instrução

“MOV A,SP” esperando-se que melhor elucide sobre o funcionamento do pipeline de dois estágios

e da importância das duas máquinas de estados. A linha azul vertical sinaliza que foi descodificada

uma instrução do tipo MOV A,(direct) (rever Capítulo 2.2.5).

Figura 19 - simulação pipeline mov a,sp

Como se pode verificar, no mesmo ciclo de relógio é ativado o valor do endereço de leitura

(rd_addr) sendo que no ciclo de relógio seguinte, início da instrução seguinte, se obtêm os dados

da memória, ou seja, o conteúdo do SFR SP (seta azul).

Um ciclo de relógio depois, o registo A já possui a cópia do valor do SP. Porém, caso a

segunda instrução tente aceder ao valor do registo A, teria um valor errado se não fossem utilizados

mecanismos de register forwarding. Isto deve-se à presença de um data hazard do tipo RAW (Read

After Write).

Os sinais de controlo associados à máquina de estados combinacional são seguintes:

Sinal codificado do endereço de leitura da memória de dados;

Sinal de escrita do PC;

Sinal codificado de seleção de fonte para escrita no PC;

41

Sinal codificado para comparação;

Sinal indicativo de operações de RMW (read-modify-write);

Sinal indicativo de necessidade de escritas;

Sinal indicativo de instrução endereçável ao bit.

Os sinais de controlo associados à máquina de estados sequencial são seguintes:

Sinal codificado de seleção de fonte para escrita na memória de dados;

Sinal codificado de seleção da primeira fonte para a ALU;

Sinal codificado de seleção da segunda fonte para a ALU;

Sinal codificado de seleção da terceira fonte para a ALU;

Sinal de identificação da operação da ALU;

Sinal de escrita para a memória de dados;

Sinal de ativação do registo PSW;

Sinal codificado de seleção da fonte do carry;

Sinal de escrita específico para os SFR.

Os sinais aqui referenciados como codificados são um mero indicativo de que o seu valor

numérico representa apenas uma palavra de controlo que será descodificada por uma unidade de

controlo local. Desta forma é possível descentralizar o esforço da unidade de controlo havendo

menor aglomeração de sinais variáveis contribuindo para uma diminuição da temperatura, o que

acaba por resultar em menor dissipação de potência; também se reduz a potência dinâmica devido

à menor distância percorrida pelos dados no datapath sendo o excedente ao invés percorrido pelos

sinais de controlo (menos variantes e de menor comprimento de palavra). Este método foi aplicado

ao nível do RTL (Register Transfer Level) pois é difícil para as ferramentas de síntese fazerem

otimizações entre módulos ao mesmo tempo que tentam manter as hierarquias entre módulos; em

adição, esta técnica também contribui para uma gestão de código mais modular sendo mais fácil

de modificar e expandir funcionalidades. É neste tipo de situações que o placement manualmente

assistido (Figura 20) mais beneficia pois são parcas as otimizações que as ferramentas de síntese

consigam encaminhar para o back-end, ou seja, para o place and route.

42

Figura 20 - imagem de place and route

A própria máquina de estados da unidade de controlo utiliza codificação binária dado que

tem menos de oito estados possíveis, sendo estas condições menos propícias à dissipação de

potência [27].

Decoder 3.4.

A unidade de descodificação é responsável por descodificar o conteúdo da memória de

programa, ou seja, converter os opcodes das instruções em sinais que a unidade de controlo

entenda para ser possível gerar as micro-operações necessárias a cada instrução, tal como

explicado na secção anterior da unidade de controlo.

Esta camada encontra-se fortemente ligada à unidade de controlo através de constructs da

linguagem Verilog. Caso assim não o fosse, o sintetizador poderia ter dificuldades em analisar e

otimizar as ligações entre os dois módulos definidos ao nível do RTL. Esta solução procura então

precaver possíveis entraves a otimizações cross-module tendo-se revelado de simples e intuitiva

criação embora pecando por ser propícia a erros aquando da alteração dos pontos de inserção das

micro-operações (para instruções que necessitem de mais do que um ciclo de relógio).

Todas as instruções com os respectivos opcodes encontram-se em anexo.

43

Detalhes de Implementação 3.4.1.

Como se pode verificar, certas instruções encontram-se divididas ao nível do registo, ou

seja, existe por exemplo uma distinção entre os opcodes para uma instrução que mova um valor

imediato para o registo R7 e uma instrução que mova um valor imediato para o registo R6. Desta

forma, uma implementação baseada em todo o comprimento do opcode resultaria num overhead

na lookup-table com efeitos nefastos sobre a potência dissipada nessa área.

Foi então elaborada uma estratégia baseada nas potencialidades da linguagem Verilog

permitindo a criação de grupos de instruções que aglomerem operações idênticas tal como se pode

verificar na Equação 6.

{ }

{ }

Equação 6 - aglomeração de registos

Para tornar possível esta aglomeração de instruções, ao invés de simples cases (muito

semelhantes aos homólogos switch da linguagem C) foi utilizado um método de programação

baseado em declarações casez. Estas permitem definir qualquer um dos casez como contendo

combinações de três valores lógicos possíveis: valor lógico “0”; valor lógico “1” e valor lógico “?”.

Este último, ao invés de ser tratado como um estado de alta impedância, é relegado para um caso

don’t care, ou seja, todos os bits designados como sendo “z” serão ignorados pela estrutura case

restando apenas que os outros bits sejam iguais aos correspondentes no opcode a ser testado.

Na Figura 21 pode-se visualizar um caso concreto da implementação da unidade de

decoding em que, por exemplo, o OPCODE 8’b1110_1000 entrará no case LP805X_MOV_R assim

como o OPCODE 8’b1110_1010 também entrará no mesmo, obtendo-se desta forma uma

implementação mais compacta e intuitiva.

Os operandos de cada instrução são facilmente determinados por cada tipo de instrução

sendo que apenas as instruções do tipo aglomerado (referidas anteriormente) representam

operandos variáveis. Este problema foi resolvido pois, os operandos (remeter para Equação 6) são

facilmente determinados através dos bits das instruções que foram mascarados com o valor lógico

“z”.

44

Figura 21 - exemplo uso de casez

Por outras palavras, e tomando o exemplo da Figura 21, o número do registo pode ser

determinado pela construção de uma palavra composta por OPCODE[2:0]. Os bits de índice don’t

care são utilizados para obter N indicando o registo RN.

Interface de Memória 3.5.

O módulo de interface de memória é responsável pela ligação entre os diversos

barramentos de dados e controlo do microcontrolador incluindo as memórias externas. Como tal é

capaz de controlar vários tipos de interfaces por forma a fazer a ligação aos barramentos internos.

Desta forma é possível ter um suporte alargado a vários tipos de memória, quer para código quer

para dados. Esta capacidade é todavia decidida aquando da sintetização dos módulos pelo que

não existe um suporte dinâmico que teria um custo acrescido em termos de área e operabilidade o

que se traduziria em maior dissipação de potência. Este módulo otimiza ao máximo o uso de ciclos

de relógio para comunicação em detrimento do desempenho uma vez que a baixa dissipação de

potência é uma das métricas desejadas, sendo todavia possível estabelecer configurações de

acordo com a aplicação alvo.

Internamente, é também responsável pela descodificação das palavras de controlo geradas

pela unidade de controlo relativamente aos endereços de memória de código e dados

descortinando acessos diretos ou indiretos, no caso dos dados.

45


Esta unidade funciona como glue-logic entre subsistemas internos e externo do

microcontrolador estabelecendo-se como uma das principais interconexões de todo o sistema. Todo

o endereçamento é então roteado por esta unidade que de acordo com as palavras de controlo

descodificadas procede ao encaminhamento dos dados para o destino correto. Para um melhor

entendimento do seu funcionamento, pode-se decompor a interface em três: a interface à memória

interna de dados, a interface à memória externa de dados e a interface à memória de código. Não

existe então qualquer troca de conteúdos explícita entre os três endereçamentos pelo que as

interfaces foram desenvolvidas isoladas umas das outras, simplificando também o processo de

desenho e codificação.

A memória interna de dados partilha os seus endereços de leitura e de escrita com outros

elementos do microprocessador, tal como os registos de propósito geral e os registos de propósito

especial. É então com base nas palavras de controlo que os endereços de leitura e escrita são

recalculados como se pode verificar na Figura 22.

Figura 22 - seleção de endereços dados internos

A descodificação do endereço de leitura é semelhante, mantendo também a condição por

defeito de transformar o endereço de escrita num valor indeterminado o que facilita o processo de

verificação e validação.

Ainda associado à memória interna de dados está a tarefa de decifrar se a operação deve

ser efetuada com endereçamento direto ou indireto. Estas operações devem ser diferenciadas pois

os endereços de escrita são disponibilizados no barramento um ciclo depois dos endereços de

leitura. Isto deve-se ao facto de os endereços de leitura serem descodificados combinacionalmente

46

de acordo com o opcode da instrução enquanto os endereços de escrita atrasados um ciclo de

relógio, inerente ao pipeline de dois estágios. Na Figura 23 pode-se visualizar a forma como as flags

são controladas.

Figura 23 - flags de acesso indireto

Através destas flags é então possível decidir qual a memória de dados fonte que deve

entrar no barramento para ser escrita no destino. Este passo foi necessário devido à partilha do

barramento de endereços entre a memória de dados interna direta que se encontra mapeada nos

cento e vinte e oito bytes mais significativos, a memória da onde se encontram os SFRs e a

memória interna de dados que pode ser acedida direta ou indiretamente, como se pode verificar na

Figura 24. É ainda importante referir que uma solução alternativa de barramentos de alta

impedância ou coletor aberto não foi levada avante apesar de poder beneficiar da seleção de qual

a memória a ser lida; desta forma apenas se ativaria o sinal de enable da memória endereçada,

reduzindo a dissipação de potência de uma leitura de todas as memórias e descodificação da fonte

a utilizar, tal como visto na Figura 24.

Porém, uma vasta quantidade de memórias disponíveis em bloco de FPGA ou mesmo

bibliotecas ASIC, quando utilizadas com sinal de read-enable requerem que este seja registado no

ciclo de relógio anterior; outras variantes requerem apenas que este esteja ativado no próprio ciclo

de leitura.

O interface para a memória de dados externa interna e externa é baseado num barramento

wishbone que é um barramento de dados de código aberto utilizado para integrar diferentes tipos

de sistemas.

47

Figura 24 - seleção da fonte de saída da memória interna de dados

Sendo este um barramento standard genérico capaz de integrar vários sistemas presentes

no mercado suporta três tipos de topologias diferentes: (1) barramento partilhado; (2) barramento

em pipeline e (3) barramento em cruz. Como tal, a latência associada a este tipo genérico tornava-

se num contra-senso aquando da implementação de um microcontrolador de baixa dissipação de

energia; foi então otimizado o barramento por forma a permitir rápidos ciclos de leitura e escrita

com o mínimo de latência possível reduzindo consideravelmente a energia despendida por cada

operação e melhorando ao mesmo tempo o desempenho do sistema, fruto da conclusão de tarefas

em menos ciclos de relógio.

Esta otimização consiste então num handshake especulativo que prevê sempre que

operações de leitura e escrita sejam concluídas com sucesso devido à não existência de arbitragem

no acesso ao barramento. Esta otimização é mantida mesmo com a existência de um controlador

DMA (Acesso de memória direto), bastando que para tal sejam utilizadas memórias dual-port

permitindo a coexistência entre o CPU e o controlador de DMA sem ser necessário arbitragem no

acesso ao barramento.

Foi então obtida uma redução nos ciclos de relógio sem impacto na potência dissipada

pelo que melhorou-se ao mesmo tempo o desempenho e consumo de energia. Foi então

desenvolvido um testbench, apresentado na Figura 25, que conta o número de ciclos que demora

uma escrita e leitura sucessiva em diferentes versões de memórias externas de dados (versão

wishbone original e versão otimizada). Como se pode verificar na Figura 26 comprova-se uma

redução de três ciclos de relógio; este tipo de operações beneficia de uma melhoria em

desempenho na ordem dos 40%.

48

Figura 25 - testbench para xram wishbone

Esta implementação utiliza também menos recursos devido à menor utilização de

elementos sequenciais. Existe todavia uma poupança de energia na ordem os 40% relembrando a

proporcionalidade direta do tempo aquando do cálculo da energia despendida.

49

Figura 26 - comparação entre barramentos wishbone

A interface para a memória de código foi desenvolvida por forma a suportar acessos a

memórias internas e a memórias externas. Desta forma é possível sintetizar um sistema com

memória de código limitada, reduzindo a área ocupada e conseguinte o custo de produção, sem

deixar de beneficiar da possibilidade de conectar uma memória externa por forma a expandir o

espaço de endereçamento para aplicações que exijam uma maior quantidade de memória.

Existem dois datapath (Figura 27) conectados a esta interface: um utilizado para o fetch de

instruções e outro como fonte para escrita no barramento SFR, mais especificamente, para escrita

no acumulador caso se trate de uma instrução que leia dados da memória de código.

Figura 27 – seleção do datapath para a ROM

50

Na Figura 28 pode-se visualizar o esquema de memória global desenvolvido podendo ser

comparado com a Figura 14 que retrata um esquema clássico.

Figura 28 - esquema de memória do LP805X

Subsistema ROM (Read Only Memory) 3.6.

A ROM consiste num espaço de endereçamento dedicado ao armazenamento do código

binário das instruções executáveis pelo CPU assim como de dados só de leitura. O módulo que

encapsula a ROM tem um impacto direto no desempenho do CPU dado que é a fonte principal de

onde o CPU retira as instruções (a outra fonte é relativa a instruções emuladas, utilizadas, por

exemplo, para gerar instruções de salto aquando no atendimento às interrupções). Sendo assim, a

velocidade com que o módulo é capaz de emitir código tem impacto direto na latência entre

instruções, devido ao pipeline de dois estágios que permite a resolução de instruções num único

ciclo de relógio.


Existem vários tipos de memórias capazes de fornecer a funcionalidade de uma ROM,

desde memórias formadas por blocos de memória RAM, baseadas em combinações de LUTs ou

mesmo memórias físicas dedicadas tais como as memórias flash utilizadas pela grande maioria

dos microcontroladores atuais. Os grandes fabricantes de FPGAs recomendam a utilização de cores

51

parametrizáveis fornecidos pelos próprios fabricantes; estes, regra geral, permitem configurações

tais como: (1) tamanho da palavra de memória; (2) quantidade de palavras, (3) espaço de

endereçamento, (4) ficheiro de inicialização de memória e (5) tipo de recurso físico utilizado para

compor a memória.

Apesar da solução inicial se ter baseado unicamente neste tipo de cores para permitir um

rápido desenvolvimento do protótipo inicial por forma a testar a unidade de decoding, em breve se

mostrou demasiado singela. Não era possível lidar com várias arquiteturas alvo devido a pequenas

nuances entre os cores disponibilizados pelos fabricantes sendo que faltava também uma glue-logic

capaz de otimizar a integração da memória com sistema; nomeadamente no suporte a código de

instruções não-alinhado na memória.

Antes de se apresentar o esquema de memória utilizado é de relembrar alguns factos

relativos ao 8051. O formato de instruções tem um comprimento variável de um até três bytes e a

memória de código é endereçada ao byte. Pode-se então concluir que o número de ciclos

necessários para o fetch de uma instrução completa está dependente do tamanho e quantidade de

palavras que a ROM permita ler simultaneamente.

Como se pode verificar na Tabela 9, uma ROM de comprimento de palavra de trinta e dois

bits permitiria executar uma instrução de três bytes alinhada no endereço zero. Todavia, uma

instrução não-alinhada, mesmo de inferior comprimento requer a leitura de duas posições de

memória diferentes. Para evitar ciclos de relógio adicionais são utilizadas memórias dual-port que

permitem a leitura de dois endereços consecutivos da ROM sendo suficiente para a construção de

qualquer instrução.

Tabela 9 - fetch de instruções da ROM

Endereços ROM Endereços 8051 Código Instrução Instrução

0

0 0x85

MOV P1,P0 1 0x80

2 0x90

3 0x74 MOV A,#5

1

4 0x05

5 0xA8 MOV R0,B

6 0xF0

7 0xEA CLR A

52

Foram então utilizadas memórias dual-port de trinta e dois bits embora teoricamente se

obtivesse o mesmo efeito com memórias de dezasseis bits de comprimento. Todavia, a utilização

de trinta e dois bits permite simplificar o processo de fetch e armazenamento. Seria ainda menos

proveitoso ao utilizar memórias de metade do comprimento pois no caso de endereços ímpares

não seria possível obter palavras de trinta e dois bits utilizando memórias dual-port. Na Figura 29

pode-se visualizar o código Verilog que descortina os acessos e constrói palavras de trinta dois bits

para qualquer tipo de leitura à memória de instruções, alinhado ou não alinhado.

Figura 29 - código verilog accessos à ROM

O módulo que encapsula a ROM foi também customizado permitindo flexibilidade no uso

de memórias desenvolvidas pelos vários fabricantes de FPGA assim como a utilização de memórias

codificada em RTL. É também possível configurar a memória para o tamanho requerido, por

exemplo, pelo ambiente que integra o sistema operativo no microcontrolador.

No suporte à combinação entre memória interna e externa de instruções, o endereço de

leitura é verificado pelo que caso seja superior ao permitido para a memória interna não é efetuada

qualquer leitura permitindo, uma poupança de energia tanto maior quanto os acessos às memórias

externas. Na geração do código executável deve ser garantido que a primeira instrução seja

alinhada, caso contrário poderia originar instruções compostas por bytes da memória interna e

externa.

53

Memória Interna de Dados 3.7.

Revisitando a ISA, a quantidade de memória interna de dados equivale a 256 bytes. Esta

encontra-se dividida em dois blocos de 128 bytes: o primeiro bloco pode ser considerado como

uma memória de propósito geral partilhando parte do endereçamento com quatro registos de

propósito geral (R0-R7), uma área dedicada ao endereçamento ao bit; o segundo bloco pode ainda

ser dividido em dois espaços de endereçamento, direto e indireto, sendo o primeiro reservado aos

registos de função especial e o segundo à memória de propósito geral, podendo ser utilizado como

memória para a pilha.

Esta memória foi então dividida em módulos diferentes devido aos diferentes datapaths

associados, nomeadamente relativo aos SFRs e à memória de dados propriamente dita.


Devido às particularidades da memória interna de dados, nomeadamente no suporte ao

endereçamento ao bit, foi necessário encapsular algumas extensões sobre um bloco de RAM por

forma a resolver toda a complexidade de acessos de forma transparente à interface de memória.

Esta liga-se então apenas a um bloco que simula as funcionalidades que as RAMs não suportam

nativamente devido à sua homogeneidade no acesso a dados. Este módulo tem então como

entradas os endereços de leitura/escrita, ao byte e ao bit, e respetivos valores de leitura/escrita

assim como uma flag de controlo que indica ao módulo se a operação corrente é do tipo

endereçado ao bit ou ao byte. Tal é necessário pois os endereços da área endereçável ao bit são

também endereçáveis ao byte. Sendo assim, como toda a memória de propósito geral é

endereçável ao byte, é instanciada uma memória endereçável de comprimento de palavra de 1

byte, capaz de armazenar 256 bytes. Apesar do módulo ser preparado para utilizar vários tipos de

memórias dos vários fabricantes de FPGA, tal escolha deve ser cuidada para não comprometer o

suporte de operações de leitura e escrita sobre o mesmo endereço. Este cenário é todo passível de

ocorrer dado o pipeline de dois estágios em que pode ocorrer uma escrita da instrução anterior

aquando de uma leitura promovida pela instrução posterior. Trata-se então de um hazard de dados

que devido ao suporte limitado nos cores disponibilizados pelos fabricantes de FPGA, poderá

resultar em comportamentos indefinidos aquando leituras sobre o mesmo endereço de escrita.

54

Foram então desenvolvidas duas soluções com garantias de leitura do valor correto. A

primeira reside na utilização dos ditos cores com lógica adicional sobre o barramento de leitura

sendo efetuado um bypass ao valor lido da memória em detrimento do dado a ser escrito para a

memória, caso se trate da etapa final de uma escrita sobre o mesmo endereço. O código Verilog

utilizado para o efeito pode ser visualizado na Figura 30.

Figura 30 - resolução de hazard sobre a leitura de RAM

Outra solução foi a criação de uma memória em RTL codificada com esta proteção já

embutida no core (Figura 31) possibilitando que a ferramenta de síntese utilize recursos de

memória dedicados da arquitetura FPGA que suportem a resolução interna do hazard.

Figura 31 - leitura de RAM com resolução de hazard embutida

Qualquer destas soluções poderá ser utilizada ficando a critério da interface de ambiente

integrado qual do caminho a tomar.

55

Os registos de propósito gerais encontram-se mapeados fisicamente na própria memória

de dados instanciada, o que facilita a sua resolução sendo apenas necessário a resolução do

número do banco selecionado, que é obtido pela combinação dos bits RS0 e RS1 do registo

especial PSW. Para tal, e por forma a evitar a necessidade de gerar leituras ao registo PSW

(também mapeado na memória) sempre que ocorram instruções que façam uso destes registos, é

utilizada uma ligação direta ao registo PSW.

A manipulação destes registos não terminou todavia aqui devido à complexidade das

instruções de endereçamento indireto. Caso se mantivesse apenas este esquema, uma instrução

do tipo MOV A,@R0 exigiria a geração de uma micro-operação para leitura do conteúdo de R0

seguida de uma outra para leitura do endereço de memória dado pelo conteúdo de R0. Para

combater este entrave de desempenho e gasto desnecessário de energia, foram criados bancos

adicionais compostos por apenas dois registos sendo cópias dos seus homólogos que se

encontram mapeados em memória. Uma cópia de registos adicionais seria desnecessária pois

apenas os registos R0 e R1 podem ser utilizados em instruções de endereçamento indireto. Sendo

assim, foi criada uma unidade de controlo de acessos indiretos que armazena estes mesmos

bancos. O armazenamento por si só não traria vantagens pois o conteúdo já é armazenado em

memória; como são apenas oito conjuntos de um byte são utilizados registos que permitem a

leitura assíncrona, ou seja, é possível obter através de lógica combinacional o conteúdo do registo

utilizado para o acesso direto. Desta forma é possível gerar as referidas micro-operações no mesmo

ciclo de relógio obtendo-se ganhos de desempenho consideráveis apenas com um ligeiro overhead

em termos de área.

Na Figura 32 pode-se visualizar o testbench do teste do acesso indireto comprovando-se

que a instrução MOV A,@R0 de opcode 0x66 é executada num único ciclo de relógio derivado do

pipeline de dois estágios. No segundo ciclo de relógio já se obtém o conteúdo da memória

apontada pelo que no terceiro ciclo o valor já se encontra efetivamente escrito no registo

acumulador.

De acordo com a ISA, os registos de propósito especiais (SFRs), encontram-se mapeados

nos 128 bytes mais significativos da memória de dados interna sendo acedidos apenas através de

endereçamento direto.

56

Figura 32 - testbench do acesso indireto por registo

Existe então a necessidade de criar área de armazenamento para cada um destes registos,

seja através de um bloco que aglomere todos os registos ou através de armazenamento individual.

Ficou todavia claro que um bloco de armazenamento, ou por outras palavras, uma memória RAM

de 128 bytes não serviria para o propósito dada a natureza volátil deste tipo de registos: a qualquer

momento podem existir triggers de hardware tais como alterações nos portos I/O que devem ser

propagados até aos registos, o que tornaria a gestão de memória demasiado complexa e

ineficiente. Optou-se então por criar individualmente cada SFR através de flip flops de um byte de

comprimento; desta forma torna-se simples o controlo individual de cada registo restando apenas

criar uma ligação partilhada por todos.

Foi então desenvolvido um módulo encarregue de gerir uma variedade de SFR. Desta

forma encapsulam-se os registos removendo a poluição na hierarquia principal permitindo também

controlar algumas situações que possam ocorrer. Por exemplo, a instrução INC DPTR faz uso de

uma soma na ALU entre o registo DPL e o valor zero com carry de um; o overflow nesta operação

indica que o valor do registo DPH deve ser incrementado por uma unidade pelo que o segundo

destino da ALU deve ser encaminho para o DPH. O módulo SFR controla então o datapath para o

caso deste tipo de operações especiais. Todas as leituras de registos são controladas pelo módulo

num multiplexador de número de entradas variáveis com os registos configurados, sendo as

escritas controladas dentro do próprio registo de acordo com as características de cada um. Por

exemplo, o registo PSW requer ligações permanentes ao registo de carry, carry auxiliar e overflow.

Desta forma, com a sincronização de todos os valores de leitura no barramento no mesmo local

não são necessários buffers de três estados estados para controlar o direito de escrever no

barramento caso a escrita fosse decidida dentro de cada SFR.

57

Com vista à modularidade foi ainda desenvolvida outra possibilidade de ligação de SFRs,

nomeadamente para controlo de periféricos ou outras funcionalidades. Estes podem ser ligados ao

barramento SFR através de buffers de três estados pelo que deve ser garantido o uso de diferentes

endereços de leitura e escrita para cada um dos SFR por forma a não entrar em conflito no drive

das linhas de dados. Como se pode verificar na Figura 33, o valor do registo é armazenado sendo

somente fornecido à saída “data_out” quando o endereço de leitura for o seu próprio endereço,

caso contrária a saída permanece em estado de alta impedância.

Figura 33 - leitura sobre ligação de três estados SFR

Pode então ser utilizada qualquer uma das formas de ligação dos SFR, tendo-se utilizado

durante o desenvolvimento do sistema uma ligação híbrida consistindo na combinação entre o

referido módulo SFR, contendo os registos que fazem parte da ISA assim como alguns periféricos

clássicos, e registos criados para novos periféricos e para o controlo de funcionalidades estendidas

tal como controlo de frequência ou mesmo paragem completa de partes da árvore de relógio.

Unidade Lógica e Aritmética 3.8.

Esta unidade, comummente chamada de ALU, é responsável pelas operações lógicas e

aritméticas fazendo parte do core do microprocessador. Em geral, as características da ALU

tendem a influenciar consideravelmente o microprocessador, nomeadamente em termos de área

ocupada e desempenho não devendo a sua influência ser negligenciada. Uma customização entre

as instruções que a ALU suporte aliada a um leque de diferentes implementações

58

(microarquitectura) permite a escolha de uma implementação escrupulosamente de acordo com os

requisitos da aplicação alvo.


A ALU está localizada no segundo estágio do pipeline sendo encarregue de operações

lógicas e aritméticas assim como o cálculo dos endereços carregados para o PC referentes a

instruções de salto e o cálculo de endereços referentes aos acessos à memória.

No total, são suportadas dezasseis instruções diferentes sendo catorze destas constituídas

apenas por lógica combinacional. Desta forma é possível resolver as ditas operações no mesmo

ciclo de relógio o que contribui muito para a performance e poupança energética (devido à redução

de ciclos por instrução) devido à utilização frequente da ALU e à sua presença no datapath.

Este módulo recebe apenas três operandos de oito bits (o terceiro é apenas utilizado para

cálculo de endereços para acesso à memória pelos registos PC ou DPTR) e três sinais de entrada.

Estes três sinais são as flags de carry, auxiliary carry e uma outra utilizada apenas para instruções

com operações endereçáveis ao bit (bit-wise). Por último, é ainda utilizado um sinal de controlo de

quatro bits utilizado para selecionar a operação que deve ser executada (sinal proveniente da

unidade de controlo, tal como apresentado em 3.3.1).

As operações suportadas pela ISA 8051 são as seguintes:

ADD: soma entre duas fontes;

ADDC: ADD com carry;

SUBB: subtração entre duas fontes com carry;

INC: incremento de um;

DEC: decremento de um;

MUL: multiplicação de duas fontes;

DIV: divisão de duas fontes;

DA: ajuste decimal;

CPL: complemento;

ANL: “e” lógico;

ORL: “ou” lógico;

XRL: “ou” exclusivo lógico;

CLR: reduz fonte a zero;

59

RL: roda para a esquerda;

RLC: roda para a esquerda com carry;

RR: roda para a direita;

RRC: roda para a direita com carry;

SWAP: troca bits;

NOP: não é efetuada nenhuma operação.

Apesar de estas serem dezanove operações diferentes, a unidade de ALU desenvolvida

executa apenas dezasseis instruções diferentes. As duas restantes instruções são resolvidas de

forma diferente promovendo uma redução de área de duas formas:

1. Em relação a recursos que seriam utilizados pelas operações;

2. Em relação à codificação de controlo da operação pois, mais uma ou duas operações

conduziriam à colocação de um bit adicional para a palavra de controlo.

Desta forma, a ALU recebe uma palavra de controlo de quatro bits de comprimento, o que

equivale apenas a um total máximo de dezasseis instruções diferentes. Para além da redução do

custo da palavra de controlo, esta restrição a dezasseis operações proveio do custo acrescido do

uso de multiplexadores em plataformas FPGA.

As instruções ADD com e sem carry são então aglomeradas numa única instrução tirando

partido da flag carry que faz parte dos sinais de entrada do módulo. Sendo assim, foi fácil

aglomerar as duas instruções numa. A unidade de controlo define então o sinal de carry de entrada

na ALU:

1. Sendo zero no caso da operação ADD;

2. Sendo o carry in do registo PSW no caso da operação ADDC.

A instrução de CLR reduz a fonte a zero, quer sejam operações endereçáveis ao byte ou ao

bit. Assim sendo, removeu-se esta operação da ALU sendo substituída por outras operações através

das micro-operações da unidade de controlo. Como exemplo, a instrução CLR A foi substituída por

uma subtração entre A e A, originando então um resultado de zero.

As operações de INC e DEC são responsáveis, como o próprio nome indica, pelo

incremento e decremento, respectivamente, de uma unidade. Como estas instruções não utilizam o

carry, e estando a unidade de controlo a controlar a respectiva flag, utilizou-se esta flag como

controlo de operação. O ganho, em termos de área, é variável pois os recursos necessários para

60

cada operação dependem do processo de síntese da ferramenta e das opções para, partilha de

recursos.

As instruções suportadas pela ALU e a sua respectiva codificação interna podem ser

visualizadas na Tabela 10.

Tabela 10 - opcodes de operação da ALU

Operadores Descrição Opcode

F1 * F2 Multiplicação 1111

F1 / F2 Divisão 1110

F1 + F2 © Soma com carry 1101

F1 – F2 © Subtração com carry 1100

F1 & F2 “E” lógico 1011

F1 | F2 “ou” lógico 1010

F1 ^ F2 “ou” exclusivo lógico 1001

~F1 Complemento 1000

F1 >> F2 Rotação à direita 0111

F1 >> F2© Rotação à direita com

carry

0110

F1 << F2 Rotação à esquerda 0101

F1 << F2© Rotação à esquerda com

carry

0100

F1++/F1-- Incremento/Decremento 0011

F1BCD Ajuste decimal 0010

F1 ↔ F2 Troca de conteúdo 0001

{ } Sem Operação 0000

A ALU pode ser estruturada de duas formas diferentes: em árvore onde se pode alcançar o

melhor desempenho devido aos menores tempos de propagação; ou em cadeia quando se

pretende uma menor dissipação de potência (Figura 34).

A ALU e as suas operações internas podem então ser configuradas de acordo com os

requisitos da aplicação (desempenho ou baixo consumo). Este tipo de otimização atua

estruturalmente nas ligações entre o datapath das várias operações. Os ganhos são todavia

61

dependentes da tecnologia alvo sendo necessária uma avaliação ao nível do floorplaning, ou seja,

da implementação física na tecnologia alvo.

Figura 34 - estruturas da ALU

No caso de um alvo em ASIC, ao mover as unidades físicas mais utilizadas das ALU (pode-

se obter estes dados a partir de code profiling) para os últimos multiplexadores da cadeia, ganha-se

em termos de dissipação de potência ao utilizar power gating para desligar os multiplexadores a

jusante (não foram efectuados todavia quaisquer testes em ASIC). Para o caso de alvos FPGA,

onde a aplicabilidade de power gating é reduzida foi delineada uma estratégia de acordo com as

capacidades físicas da FPGA alvo, nomeadamente na relação entradas/saída dos multiplexadores.

Para exemplificar, caso uma dada FPGA ou até biblioteca de ASIC não possua nos seus elementos

multiplexadores de três entradas, e seja necessário um multiplexador de três entradas, terá este

multiplexador de ser partido em dois de duas entradas. Neste caso poderá existir uma maior

dissipação de potência devido à área ocupada e à maior propagação dos sinais. Da

experimentação destas metodologias, e após a análise de vários possíveis cenários surgiu um novo

tipo de estrutura: uma abordagem híbrida entre a estrutura em árvore e a estrutura em cadeia,

como se pode visualizar na Figura 35.

Figura 35 - estrutura híbrida da ALU

62

Esta nova estrutura permitiu com um nível superior de flexibilidade tornar possível o ajuste

do datapath da ALU de acordo com as especificidades da aplicação alvo e da tecnologia alvo a que

se destina. Em acrescento, cada operação da ALU pode ser removida por forma a reduzir a área

ocupada pelo módulo e consequente redução da potência dissipada.

A título de exemplo, sendo a multiplicação e divisão os elementos mais custosos da ALU,

numa aplicação em que o seu uso não compense uma implementação em hardware, podem ser

removidos da ALU sendo substituídos pelos seus congéneres em software.

A implementação em Verilog do módulo da ALU beneficia de uma pequena máquina de

descodificação do opcode da operação que lhe é passado pela unidade de controlo. A utilização

inicial de um case aliada às dezasseis operações possíveis poderia resultar na síntese de

multiplexadores de 16 entradas como se pode verificar na Figura 36.

Figura 36 - MUX 16:1 ALU

No entanto tal não aconteceu pois estes elementos são escassos nas FPGA existindo

multiplexadores reais de apenas duas entradas. Todavia, através de uma combinação entre LUTs é

possível sintetizar multiplexadores de dezasseis num único slice, razão pela qual foi importante a

restrição de dezasseis operações ao nível do RTL; como se pode então verificar restam poucas

opções ao nível do RTL pois, não é possível utilizar bibliotecas de acordo com o RTL quando se

está completamente dependente da plataforma física.

63

Na Figura 37 pode-se verificar que a implementação de multiplexadores de dezasseis

entradas recorre a implementações de multiplexadores de quatro entradas através de LUTs. Estes

são ainda aglomerados através de multiplexadores nativos de duas entradas até perfazer as

dezasseis entradas ocupando um único slice.

Figura 37 - multiplexadores de 4 e 2 entradas na ALU

É ainda importante referir o módulo ALU_SEL que não estando diretamente integrado no

módulo da ALU tem uma importância crucial na execução de instruções pois, é responsável pela

seleção dos operandos da ALU. Por outras palavras, com base nas palavras de controlo geradas

pela unidade de controlo, é feita uma descodificação que identifica os operandos necessários para

a operação ALU. Esta separação foi necessária para evitar que na etapa de placement a

descodificação ficasse afastada fisicamente das fontes de dados. Desta forma evitou-se a

dissipação dinâmica de potência resultante das ligações de doze sinais diferentes que seriam

encaminhados para a ALU. Ao descodificar a palavra de controlo numa posição que seja a mais

afastada possível da ALU reduz-se o caminho percorrido pelos doze sinais sendo o resto percorrido

64

por apenas três sinais de 8 bits de comprimento promovendo uma redução de potência

considerável.

Os operandos são descodificados através de multiplexadores e inicialmente foram

utilizados multiplexadores de número de entradas iguais ao número de fontes possíveis para cada

operando por forma a reduzir o comprimento da palavra de controlo. Todavia, esta estratégia foi

modificada devido à desnecessária dissipação de potência que ocorria quando a ALU não era

necessária em determinada instrução. Isto acontecia pois o descodificador era otimizado de acordo

com o número de fontes pelo que a condição por defeito da descodificação era o encaminhamento

de uma fonte de sinal para operando.

Para combater esta perda desnecessária de energia optou-se por estender o comprimento

da palavra de controlo sendo possível a atribuição de uma condição por defeito que reduzisse a

dissipação de potência. Apesar da manutenção do estado do sinal ser uma estratégia capaz de

reduzir a dissipação de potência através da redução do número de transições (tal como

apresentado no estado da arte), esta opção é inviável para uma implementação FPGA servindo

apenas para ASIC. Isto deveu-se ao facto de ser utilizada lógica combinacional na descodificação

dos operandos da ALU que permite obter o resultado da operação no mesmo ciclo de relógio.

Assim sendo, é necessária a utilização de uma latch que beneficia de um controlo assíncrono, logo

apropriado para lógica combinacional. Todavia a utilização de latch em FPGA deve ser efectuada

com cuidado acrescido pois dificulta a análise estática temporal podendo-se obter resultados

imprecisos relativamente à frequência máxima de operação. A estratégia para FPGA passou então

pela descida da diferença de potencial para zero, removendo efetivamente a dissipação dinâmica

de potência após o sinal estabilizar. Esta estratégia é especialmente eficaz quando se executa

várias instruções seguidas que não façam uso da ALU.

Periféricos 3.9.

Os periféricos são o principal eixo de ligação entre o microprocessador e o mundo real

sendo ponto assente o seu impacto e quiçá preponderância aquando da escolha de um

microcontrolador para uma determinada tarefa. O esquema para os SFR explicado anteriormente

foi então preponderante para a criação de um barramento que permite uma fácil adaptação de

qualquer periférico para este microcontrolador potenciando, as funcionalidades do mesmo. Ao

mesmo tempo é possível criar periféricos virtuais que beneficiam do acesso SFR sendo útil para

65

fornecer alguma configurabilidade do core do microcontrolador ao programador. Os periféricos

clássicos do 8051 foram implementados, como por exemplo os portos I/O, timer01, timer2,

interrupções e porta série. Em adição foram também desenvolvidos os seguintes periféricos: (1)

gerador de números aleatórios; (2) motor criptográfico AES; (3) temporizador watchdog; (4)

temporizador configurável; (5) controlo de frequência e modos de suspensão; (6) suporte

escalonador power aware. Os periféricos clássicos como destes porém não serão referenciados em

detrimento de outros periféricos mais recentes. Tal escolha deve-se ao facto da sua implementação

ter seguido estritamente a implementação clássica do 8051 optando-se por apresentar apenas os

periféricos diferenciados cuja implementação será ilustrativa da flexibilidade inerente ao

barramento SFR.

Gerador de Números Aleatórios 3.9.1.

Este será um dos periféricos cuja implementação é de mais simples compreensão não

deixando porém de se possuir funcionalidades interessantes como a geração de números aleatórios

que se pode encontrar cada vez mais em microcontroladores comerciais, nomeadamente nas

versões que também possuem motores criptográficos dedicados.

A criação de um gerador robusto para aplicações com requisitos criptográficos seria um

desafio de matemática e inovação com scope para além daquele que é proposto neste tema de

dissertação, pelo que se optou por utilizar um motor matemático similar ao proposto na Motorola

[28]. Trata-se então de um gerador, implementado em hardware, tendo como objetivos a

imprevisibilidade da sequência de números e a não repetição de palavra, entre outros.

Para tal efeito, este motor inicia uma geração polinomial não repetida de palavras

necessitando todavia de inserção de sementes para remover a previsibilidade dos números

gerados. A alimentação das sementes pode ser proveniente de sinais internos ao microcontrolador

ou mesmo inseridas através de registos disponíveis para o efeito.

Este periférico possui então três registos associados, um para configuração de

funcionalidades, outro para inserção das sementes e finalmente um registo para ler os valores

aleatórios gerados (ver Tabela 11).

O bit de enable é utilizado para ligar ou desligar o motor de números aleatórios poupando

desta forma energia quando deixar de ser necessitado. O bit de seed deve ser colocado a um

66

sempre que se desejar que a palavra escrita no registo RNDSEED seja inserida como semente,

sendo automaticamente limpo por hardware.

Tabela 11 - registos SFR para Números Aleatórios

7 6 5 4 3 2 1 0

RNDCON enable seed mode clear reserved reserved Len_h Len_l

RNDSEED seed seed seed seed seed seed seed seed

RNDOUT out out out out out out out out

Como se pode verificar na Figura 38 o bit que controla a semente é colocado ao valor da

palavra escrita sempre que o endereço de escrita for o do registo respetivo sendo colocado a zero

no próximo ciclo de relógio.

Figura 38 - flag de seed limpa por hardware

O bit mode seleciona o modo de operação sendo que no modo zero o sinal de enable é

totalmente controlado por software e no modo um o sinal de enable é automaticamente limpo por

hardware sendo necessário recoloca-lo a um se for necessário obter novo número aleatório no

registo RNDOUT. A palavra de dois bits formada por Len_h e Len_l é utilizada para determinar o

comprimento de palavra do número aleatório sendo possível utilizar palavras de um, dois, três e

quatro bytes. Deve-se então fazer escritas, à semente, ou leituras, à palavra aleatória de saída, o

número de vezes correspondente ao número de bytes configurado.

É então utilizada uma máquina de estados indicativa de qual o byte a ser utilizado como

saída do registo sempre que existir uma operação de leitura, como se pode verificar na Figura 39.

A mesma lógica é válida para o caso de escritas no registo da semente, sendo utilizada a

mesma máquina de estados, promovendo a reutilização de recursos. Foi tendo em vista esta

partilha de recursos que surgiu a necessidade do bit clear utilizado para limpar a máquina de

estados que controla estas mesmas operações, reiniciando-a para o estado inicial de escrita ou

leitura do primeiro byte.

67

Figura 39 - leitura do número aleatório de comprimento variável

Criptografia AES 3.9.2.

O motor criptográfico AES é dos mais utilizados em microprocessadores tendo a própria

intel expandido seu instruction set para comportar instruções AES permitindo o aceleramento por

hardware. Tal como o periférico exemplificado anteriormente, não será explicado em detalhe o

funcionamento da encriptação e desencriptação AES.

Este periférico beneficia de quatro registos SFR que permitem a configuração do módulo, a

escrita dos dados a serem encriptados e a sua respectiva leitura assim como a introdução de

novas chaves de encriptação. Permite-se ainda uma configuração que une os registos de entrada e

saída de dados distinguindo-se o tipo de operação semanticamente: uma escrita no registo

AESDATA significa nova entrada de dados para codificar e uma leitura do mesmo registo irá obter o

valor já codificado ao invés do valor de entrada. Desta forma poupa-se o espaço de endereçamento

SFR podendo ser levado para um nível mais extremo através da utilização de um bit controlo para

unir o registo de escrita da chave no mesmo registo de dados.

Tabela 12 - registos de configuração AES

7 6 5 4 3 2 1 0

AESCON enable encrypt strobe ready clear Len_h Len_m Len_l

AESDATA data data data data data data data data

AESKEY key key key key key key key key

68

Relativamente ao registo AESCON, o sinal de encrypt permite configurar a motor para a

tarefa de encriptar ou desencriptar os dados transferidos através de AESDATA. O termo transferido

é o mais correto a utilizar pois os dados, presentes no registo AESDATA, poderão não se qualificar

como a totalidade da palavra a ser codificada dado o comprimento de dados configuráveis através

dos bits Len_h, Len_m e Len_l como se pode verificar na Figura 40.

Figura 40 - registo AESCON

O registo aes_sload equivale ao último byte que deve ser transferido tendo sido utilizada

lógica baseada em potências de dois. Por outras palavras, é possível codificar e descodificar

palavras de um, dois, quatro, oito e dezasseis bytes. É ainda possível configurar um comprimento

fixo de acordo com as especificidades da aplicação alvo sendo ainda possível utilizar diferentes

motores de AES de acordo com as métricas de desempenho ou poupança energética. Tal é

possível devido ao encapsulamento de todo o motor AES num módulo separado sendo apenas

necessário que as interfaces fornecidas pelos módulos sejam similares, o que foi verificado com

sucesso em três diferentes motores de AES experimentados.

Na Figura 41 pode-se visualizar o que acontece aquando da escrita para o registo

AESCON. Revisitando a estrutura do registo, o bit quatro corresponde à variável ready que indica

que uma operação AES foi concluída. Apesar da escrita com o valor zero poder significar apenas

um acknowledge por parte do software, perante a possibilidade remota de nesse mesmo ciclo de

relógio um novo dado AES estiver pronto, torna-se necessário assegurar que essas flags não fiquem

em zero caso contrário não seria detetado pelo software podendo originar um stall no sistema. Este

cenário é facilmente resolvido com uma porta “ou” entre o valor de escrita e a flag indicadora de

terminação de operação atual.

69

Figura 41 - controlo aes e transferência de dados

Pode-se também verificar pela imagem que uma máquina de estados é utilizada para

controlar a transferência de dados sempre que o tamanho configurado seja superior a um byte.

Watchdog Timer 3.9.3.

O watchdog é um tipo de temporizador encarregue de despoletar um determinado evento,

normalmente coloca o sistema num estado conhecido de reset, numa situação em que o programa

de software deixe de atualizar o watchdog como resultado de alguma falha no sistema, como por

exemplo, um stall como o que poderia ocorrer na situação explicada anteriormente no AES.

Os watchdog podem ser configurados de várias formas relativamente à sua localização

física, à fonte de relógio utilizada, ao tempo de timeout do temporizador e à ação que deve ser

desencadeada aquando deste mesmo timeout.

Este módulo foi então desenvolvido como um periférico situando-se fisicamente próximo do

CPU numa ordem de grandeza muito inferior à do respetivo timeout. A fonte de relógio que

alimenta o funcionamento das unidades sequenciais do temporizador é configurável ao nível do

RTL, permitindo utilizar uma fonte distinta daquela que alimenta o CPU permitindo que a ação

desencadeada, por exemplo a colocação de um pino externo a nível lógico baixo, aconteça mesmo

70

que o CPU cesse o seu funcionamento. Este tipo de configuração é todavia mais complexa sendo

apenas lidada no capítulo de múltipla frequência. O tempo de timeout é configurável em vários

níveis tal como será explicado de seguida sendo a ação desencadeada configurável permitindo

flexibilidade na própria ligação a elementos externos ao sistema.

Apesar da característica especial relativamente à ação desencadeada aquando um

timeout, nomeadamente a geração de um reset interno ao microcontrolador, a estrutura deste

módulo segue de perto o padrão utilizado por qualquer periférico do sistema.

Existem então três registos associados a este periférico podendo-se visualizar os mesmos

na Tabela 13.

Tabela 13 - registos SFR do Watchdog Timer

7 6 5 4 3 2 1 0

WDTCON prescaler prescaler prescaler Idle reserved swreset timeout enable

WDTRST pattern pattern pattern pattern pattern pattern pattern pattern

WDTREG timer timer timer timer timer timer timer timer

A estratégia de timeout do watchdog assenta sobre um temporizador de número de bits

configurável aquando da sintetização, ficando o timeout associado ao overflow do temporizador. O

registo WDTCON tem então três bits de pré-escalar, permitindo configurar a frequência de

contagem associada ao temporizador, sendo o valor, formado pelos mesmos, indicativo do número

de bits do mini temporizador de três bits com contagem inicial igual ao valor formado pelos três

bits de pré-escalar do registo WDTCON.

Figura 42 - contagem watchdog com pré-escalar

71

Na Figura 42 pode-se verificar que a contagem do temporizador é resultado de uma

concatenação entre um registo de tamanho estático (configurável aquando da síntese) wdtimer e

um registo pré-escalar cujo conteúdo é definido pelos três bits presentes no registo sendo efetuada

a atribuição de acordo com a imagem. Foi ainda elaborada uma estratégia de proteção em

hardware com vista a combater escritas erróneas no registo tornado o sistema mais seguro face

aos problemas de execução de software. Assim sendo, para ativar o enable do watchdog é

necessário escrever para o registo WDTRST o valor 0x1E requerendo a sua desativação a escrita do

valor 0xE1. Por forma a possibilitar opções estendidas de controlo, é ainda utilizada uma estratégia

similar para requisitar ao watchdog um reset ao microcontrolador caso o software assim o entenda

necessário; a escrita do valor 0x5A no registo WDTRST ativa o reset por software devendo ser

desligado após o sistema reinicializar com a escrita do valor 0xA5. Ainda na mesma linha de

pensamento, qualquer escrita fora de ordem ou com valor errado irá resultar num reset ao sistema.

Perante várias condições de reset, incluindo através do próprio pino de reset do microcontrolador, é

necessário que o software seja capaz de identificar qual a causa do reset e proceder de acordo. A

Tabela 14 é então indicativa das flags do registo e qual deverá ser a sua interpretação.

Tabela 14 - causas de Reset

SWRST WDTOV Causa de Reset

0 0 Pino de reset externo

0 1 Timeout do watchdog

1 0 Pedido por software

1 1 Escrita errada em WDTRST

Controlo de Potência 3.9.4.

A operação de baixa potência do microcontrolador é habilitada através de uma seleção

entre várias fontes e divisões de relógio com vista à redução da dissipação de potência dinâmica

não só pelas árvores de relógio mas também nas várias linhas de datapath, resultado de menor

atividade.

O controlo fornecido neste módulo assenta exclusivamente no relógio do sistema dado que

o principal alvo tecnológico a que este projeto se direciona, arquitetura FPGA, não permite

customizações dinâmicas ao nível da alimentação de várias camadas do sistema, tal como na

arquitetura ASIC.

72

O módulo de controlo de potência pode ser configurado estática ou dinamicamente, ou

seja, caso o microcontrolador seja configurado para determinada aplicação específica sem

requisitos de controlo de potência em tempo-real é possível sintetizar o sistema com todas as

ligações de relógio e afins configuradas para uma forma hard-wired poupando-se em área

relativamente à configuração on-the-fly. Caso a aplicação alvo possua requisitos tempo-real, onde

possa ser necessário aumentar a frequência de relógio para cumprir deadlines, é possível que uma

configuração dinâmica seja selecionada sendo o controlo conseguido através de SFRs tal como se

de um periférico se tratasse.

Para aplicações em que seja proveitoso alternar entre várias frequências de relógio,

importa analisar quais a/as várias fontes de sinal passíveis de serem utilizadas como relógio. Uma

análise apurada pode conduzir à remoção do cristal em detrimento da geração dos vários sinais a

partir de um outro sinal fonte, pese embora surjam casos em que a utilização de relógios isolados

garanta alguma margem de segurança perante a possível falha de um deles. Foram então tidos em

conta uma panóplia de cenários sendo possível adaptação de acordo com os requisitos de cada

aplicação procurando o menor overhead possível.

Considerando que a principal característica, entre as várias configurações, é a seleção de

uma fonte de relógio entre várias possíveis, foi necessário estudar as características de várias

arquiteturas diferentes de FPGA. Foram então desenvolvidas diferentes implementações para

arquiteturas da Altera e da Xilinx tendo-se aproximado ambas as soluções por forma a facilitar a

integração com o resto do sistema independentemente da arquitetura alvo.

Para ambas as arquiteturas é dada a possibilidade de geração de sinais de relógio a partir

de unidades específicas tal como PLL (Phase-locked Loop) ou DLL (Delay-locked Loop) embora

incorram num consumo de energia considerável inviabilizando a sua utilização em aplicações com

restrições mais apertadas de consumo energético. Outro possível problema é o atraso associado ao

lock de frequência, ou seja, até que os sinais de saída se encontrem estáveis o suficiente para

serem utilizados na árvore de relógio. Este pode ser um fator crítico em aplicações cuja latência é

crítica.

As árvores de relógios das FPGA são intrinsecamente distintas das suas homólogas em

ASIC pois possuem barramentos de ligação criados especificamente para conduzir sinais de relógio

com baixo skew entre as interconexões. Caso se utilizassem linhas não dedicadas de relógio

enfrentar-se-iam problemas ao nível da indeterminação dos tempos exatos de propagação entre os

elementos, resultando numa análise temporal incompleta.

73

Na Tabela 15 apresenta-se uma comparação grosseira entre recursos nativos de duas

arquiteturas Altera e Xilinx sendo recursos da árvore de relógio da primeira capazes de combinar

um número superior de entradas. Para obter o mesmo efeito na Xilinx é necessário utilizar vários

blocos de bufgmux. Estão ambas a par relativamente à PLL/DLL sendo necessário em ambos os

casos adicionar o sinal de lock à lógica do sinal de reset por forma a não permitir o funcionamento

do sistema enquanto o sinal de relógio não estabilizar.

Tabela 15 - recursos de Relógio entre Altera e Xilinx

Altera Xilinx

3.9.4.1. Múltipla Frequência

O uso de mega funções PLL/DLL5 permite obter sinais de relógio através de combinações

de multiplicação e divisão sobre o sinal original de relógio que não seriam possíveis de outra forma,

5 Estas unidades são compostas por um controlador que permite multiplicar ou dividir sinais das PLL/DLL

74

nomeadamente relativamente à multiplicação. Porém, existe pouco suporte para alteração das

frequências on-the-fly ficando-se limitado a frequências determinadas estaticamente. Para combater

este problema e considerando que regra geral em aplicações low-power será necessário uma

divisão do sinal de relógio foi implementado um módulo genérico capaz de dividir frequências de

relógio em múltiplos de dois; desta forma é possível reutilizar o mesmo módulo para diversas

arquiteturas alvo.

Este é implementado recorrendo a um contador binário onde cada bit muda de estado

numa ordem de grandeza de potência de dois elevado à sua posição na palavra (começando em

1), como se pode verificar na Tabela 16.

Tabela 16 - contador binário para divisão de relógio

f/8 f/4 f/2

0 0 0

0 0 1

0 1 0

0 1 1

1 0 0

Apesar de se tratar de uma solução genérica capaz de ser reutilizada em FPGA ou ASIC,

não é todavia suficiente para garantir uma transição segura de uma frequência de relógio para a

outra apesar das frequências serem múltiplas umas das outras.

Como se pode verificar na Figura 43, a transição de sinal é crítica podendo ocorrer

situações em que o sinal de relógio de saída se torna temporariamente numa onda desfigurada

com período diferente de qualquer dos sinais de entrada. Este facto é agravado quando o período

do sinal resultante se torna inferior ou período mínimo permitido para o sistema podendo tornar flip

flops metastáveis o que pode resultar numa falha total do sistema.

Este problema pode ser resolvido utilizando lógica adicional que impede o sinal de comutar

até que exista uma transição de nível na entrada que o relógio deve mimicar como se pode verificar

na Figura 44.

75

Figura 43 - transição de relógio com glitch [29]

Figura 44 - transição de relógio sem glitch [29]

São então utilizadas soluções distintas para FPGA e ASIC por forma a otimizar as

interconexões de cada tecnologia alvo. Na Figura 45 pode-se visualizar um desenho RTL capaz de

assegurar transições seguras de relógio em arquiteturas ASIC.

Para assegurar a mesma transição segura em FPGA não é necessária a utilização do

módulo anterior existindo recursos de hardware nas próprias arquiteturas FPGA que permitem a

seleção de relógio e drive do mesmo para barramentos dedicados de relógio.

Exemplificando a implementação baseada em arquitetura Xilinx, os recursos BUFGMUX

permitem fazer a multiplexagem e inserção de linhas de relógio possuindo ao mesmo tempo dois

mecanismos diferentes para lidar com eventuais riscos de conversão como os que foram

anteriormente apresentados.

76

Figura 45 – esquemático RTL de transição segura de relógio

Foi então utilizado o mecanismo de sincronismo que garante uma transição de fonte de

relógio sem falhas pois, atrasa a mesma até que o sinal de relógio de saída se encontre em nível

lógico baixo e exista uma transição de nível alto para baixo na fonte de relógio que passará a

conduzir o barramento.

Numa aplicação que possa beneficiar de várias frequências diferentes por forma a

funcionar na menor frequência possível e permita cumprir a deadline, a utilização de vários

BUFGMUX não será a solução adequada. Assim sendo foi elaborada uma estratégia que tira

partido das duas entradas do BUFGMUX para fazer comutações dinâmicas entre as entradas,

simulando a existência de apenas duas fontes de relógio diferentes.

Para tal foi necessário alterar o módulo divisor de relógio para lhe ser adicionada uma nova

saída. Assim sendo, a divisão de relógio passa a ter como saídas a fonte de relógio selecionada

pela configuração do registo SFR assim como a fonte de relógio que está a ser utilizada nesse

momento. Apesar de ter os contornos de uma solução complexa, trata-se de uma simples

implementação dado que fontes de relógio provêm dos índices de um contador binário, estando o

resultado final ilustrado na Figura 46.

Obtidas ambas as fontes de relógio, resta selecionar qual a sua ordem no recurso

BUFGMUX. Para tal é necessário determinar quando há necessidade de mudança de relógio,

sendo que pode ser conseguido através de um registo de um bit sendo comutado de acordo com

as escritas no registo SFR CLKSR. Resta então proceder à alteração da ordem de entrada como se

pode verificar na Figura 47.

77

Figura 46 - seleção da fonte de relógio nova e antiga

A entrada do BUFGMUX cujo sinal era alimentado pelo relógio novo passa a estar provida

do relógio antigo e vice-versa. Desta forma é possível comutar de uma vasta gama de fontes de

relógio utilizando apenas um recurso limitado ficando o resto das linhas de relógio dedicadas livres

para ser conduzidas por outras fontes de relógio como se poderá verificar na secção do

funcionamento em múltipla frequência.

Figura 47 - transição de relógio on-the-fly

78

3.9.4.2. Modos de suspensão (sleep)

Para além da possibilidade de reduzir a frequência de relógio de determinada unidade do

sistema, é ainda possível reduzir a mesma para zero o que efetivamente elimina a dissipação de

potência dinâmica dessa mesma unidade. A utilização de técnicas de clock-gating para arquiteturas

FPGA deve ser muito cuidada pois uma simples utilização semelhante a uma técnica ASIC, como

se pode visualizar na Figura 48, pode trazer complicações no processo de implementação e

verificação.

Figura 48 - exemplo de clock-gating

A utilização de clock enables dos próprios flip flops é também útil para reduzir a comutação

dos sinais não sendo todavia capaz de reduzir a potência dissipada pela própria árvore de relógio.

Esta técnica de uso dos enables é então utilizada por todo o sistema para redução de propósito

geral não sendo utilizada especialmente para desligar a árvore de relógio.

A técnica exemplificada na Figura 54Figura 49 é proposta pelo fabricante Altera como forma

de garantir que o sinal gerado seja livre de glitches devido à introdução do elemento sequencial.

Figura 49 - clock-gating recomendado pela Altera

Este modelo foi adaptado para utilizar uma porta “ou” ao invés da “e” devido à lógica

posedge clock utilizada por todo o sistema do microcontrolador. Caso a frequência máxima de

relógio seja degradada acima de um valor aceitável, é ainda possível converter este modelo por um

79

modelo de clock enables através de opções automáticas da ferramenta EDA que removem bastante

trabalho por parte do projetista.

Na família de arquitetura da Xilinx aproveitou-se os recursos BUFGMUX utilizando os mesmos

para conduzir a linha de clock a zero reduzindo a dissipação de potência dinâmica de uma forma

mais transparente para a ferramenta EDA pelo que se espera resultados mais fiáveis relativamente

à frequência máxima possível para o relógio.

A forma por excelência de redução da dissipação de potência na sua quase totalidade passa

pela utilização de técnicas como power-gating. Este tipo de abordagem é todavia bastante

complicado em arquiteturas FPGA sendo mesmo impraticável devido à falta de recursos específicos

para o efeito. Apesar de fabricantes como a Xilinx anunciarem para futuro capacidades para

desligar determinadas áreas dos seus chips (fine-grain), não foi ainda possível confirmar o mesmo.

Apesar deste senão que coloca a arquitetura ASIC à frente da FPGA (neste domínio de

competição), tanto em arquiteturas Xilinx, como por exemplo na Actel, é possível colocar o chip (na

sua totalidade, ou seja, de forma coarse-grain) em modos de suspensão reduzindo a potência

consumida para valores quase negligentes de consumo para a maioria das aplicações. Pese

embora esta funcionalidade de valor acrescido, é necessário precaver individualmente o sistema de

acordo com o fabricante e família de arquitetura alvo pois, existem diferenças inerentes à sua

utilização. Estas diferenças devem ser colmatadas através da ferramenta IDE [25] utilizando as

virtudes da modelação em alto nível.

A Tabela 17 apresenta as funcionalidades possíveis de acordo com a tecnologia alvo.

Tabela 17 - Implementação de modos de suspenção em várias tecnologias

Modos de Suspensão

Tecnologia Alvo Ativo Idle (/parcial) Sleep Shutdown Partial Sleep

ASIC Sim Sim Sim Sim Sim

Actel Sim Sim Sim Sim (alguns) Não

Xilinx Sim Sim Sim Não Não

Altera Sim Sim Não Não Não

No modo Idle apenas o relógio é efetivamente desligado reduzindo grande parte da energia

dinâmica. No modo sleep são desligadas todas as alimentações exceto as necessárias para a

manutenção do conteúdo que representa o estado do microprocessador. No modo de shutdown é

desligada toda a alimentação do sistema reduzindo a potência dissipada para zero sendo no

80

entanto necessário tomar precauções para armazenar o estado do microcontrolador numa

memória externa caso assim seja necessário.

Apesar da complexidade em perceber e integrar todo o processo de suspensão no

microcontrolador a sua utilização é consideravelmente simplista bastando configurar um pino com

a capacidade de ativar o modo de suspensão. Em fabricantes como a Actel, quando o modo de

suspensão Idle for utilizado para todo o chip não é necessário recorrer a um clock-gating manual

podendo também ser utilizado um pino para ativar este mesmo modo de maneira mais segura.

Quando se desejar colocar em Idle apenas certo periférico, por exemplo, utiliza-se o clock-gating

apenas nessa específica linha de relógio que esteja dedicada ao próprio periférico. Esta

configuração deve ser efetuada aquando do desenho do microcontrolador pois poderão existir

periféricos cujo tempo de vida seja partilhado não havendo necessidade de utilizar linhas de relógio

separadas, que são escassas em FPGA. Para acordar o chip destes modos basta que exista uma

transição positiva no respetivo pino de AWAKE que pode ser levada a cabo por um temporizador

externo ou mesmo por um temporizador interno caso o chip em causa tenha uma tensão de

alimentação especial para o efeito, pode-se utilizar um RTC para acordar o microcontrolador em

tempos de baixa granularidade. A utilização do pino de AWAKE diretamente permite acordar o

sistema como que de uma interrupção externa se tratasse sendo útil por exemplo para aplicações

baseadas em sensores onde só devem consumir energia quando existir um pedido numa

determinada linha de select, como se pode verificar na Figura 50 - acordar microcontrolador com

interrupção externa.

Figura 50 - acordar microcontrolador com interrupção externa (retirado de [30])

81

Suporte Escalonador Power Aware 3.9.5.

Durante a fase de testes do microcontrolador, um dos executáveis mais utilizados era

relativo ao sistema operativo cujo porting foi efetuado em simultâneo, sendo este dotado de dois

diferentes tipos de escalonadores: um preemptivo e um power aware. Relativamente ao

escalonador power aware, e sem entrar em demasiados detalhes, as suas tarefas possuem

atributos adicionais tais como: período, deadline, Worst Case Execution Time (WCET) e o tempo

restante até atingir a deadline. É com base nestes atributos que se calcula a frequência mínima a

que o processador pode operar sem correr o risco de falhar os deadlines. Durante a realização de

simulações foi detetado que a rotina responsável pela decisão da frequência necessitava de um

número de ciclos de relógio bastante considerável. O tempo perdido nesta rotina colocava em

causa a própria utilização do escalonador pois eram perdidos numerosos ciclos de relógio a cada

tick do temporizador de sistema, ou seja, em cada ponto de escalonamento.

Foi tendo em conta este entrave de software que se optou por efetuar o porting desta

morosa função para hardware por forma a promover o seu desempenho nos pontos de

escalonamento.

Figura 51 - rotina de escolha de frequência power aware

82

Na Figura 51 apresenta-se o código C++ responsável pela seleção da frequência mínima

possível que permita atingir a deadline e respetiva escrita no SFR de controlo de frequência. Se

fosse possível caracterizar a função em termo de entradas e saídas seria dito que a entrada é um

valor de ponderação que deve ser comparado a um conjunto de fatores associados às frequências.

Estes fatores podem ser encarados como a capacidade de trabalho que consegue ser efetuado a

uma dada frequência sendo que o primeiro fator maior do que o valor de entrada será utilizado

para definir a frequência mínima permitida. A saída da função seria então o valor de escrita no

registo que configuraria o relógio do microcontrolador para a frequência em causa.

A primeira etapa de conversão passou então por criar um módulo periférico com registos

SFR para escrita e leitura dos supostos valores que a função usaria. Posto isto, foram criados dois

registos SFR que devem ser escritos com o valor de ponderação referido anteriormente sendo que

a sua leitura indicará o valor que deve ser escrito no registo de configuração de relógio. Os registos

SFR podem ser visualizados na Tabela 18.

A comparação entre o valor de ponderação e os fatores associados às frequências poderia

ser resolvida recorrendo apenas a lógica combinacional, porém seriam necessárias oito unidades

de comparação paralelas. Foi então optado pela solução sequencial que compara fator a fator

tendo uma penalização máxima igual ao número de frequências de teste. No caso específico tem

uma latência mínima de um ciclo de relógio (quando é selecionada a frequência mínima) e uma

latência máxima de nove ciclos de relógio (quando é selecionada a frequência máxima).

Tabela 18 - registos SFR do módulo escalonador

7 6 5 4 3 2 1 0

SCHEDH start enable clock clock clock factor factor factor

SCHEDL factor factor factor factor factor factor factor factor

São então criados valores constantes para os fatores de frequência divididos por dezasseis

em relação aos utilizados na rotina de software. Desta forma é possível fazer a chamada da função

através de um parâmetro unsigned int ao invés de um float bastando para isso multiplicar um

parâmetro de proporcionalidade direta por dezasseis obtendo-se degraus de seis pontos

percentuais. Desta forma consegue-se também uma gama de oito frequências possíveis face às

três suportadas pela implementação em software.

83

Apresenta-se então na Figura 52 parte da implementação do módulo. Como se pode

verificar o sistema começa a verificação de qual a frequência adequada após a escrita de um na

flag start do SFR respectivo. Enquanto o módulo se encontrar ativado, ou seja, em enable, são

efetuadas comparações entre o valor de ponderação e as escalas de frequência, pelo que assim

que o sistema encontrar um match permitir que seja efetuada uma leitura ao registo para obter

qual a palavra que deve ser escrita no registo de controlo de frequência.

O código C++ necessário para usar este módulo é consideravelmente mais simples

podendo ser visualizado na Figura 53.

Figura 52 - suporte por hardware a escalonador power aware

84

Figura 53 - código C++ para utilizar suporte a escalonador power aware por hardware

Suporte para Múltiplas Frequências 3.10.

A utilização de componentes do sistema a frequências diferentes pode ser utilizada em

duas frentes: (1) redução de energia dissipada devido à diminuição da frequência a que certas

unidades operam e (2) melhoria de desempenho fruto de um aumento de frequência temporário

ou permanente. Pode ainda ser utilizada uma estratégia híbrida em que se configura cada

componente do sistema para a sua frequência ideal de funcionamento estática ou dinamicamente.

Esta aventura deve ser porém tomada com cuidado para não agravar a utilização da energia que

se pretende poupar. Por outras palavras, nem sempre uma menor dissipação de potência fruto de

redução de frequência pode significar poupanças energéticas tal como visto na imagem 1 do

capítulo 1. Podem ainda existir mais cenários, como por exemplo, aplicações de energy harvesting

em que a energia que não seja utilizada se perde, pelo que compensará trabalhar a uma

frequência que garanta o deadline tratando-se esta da localização no tempo em que o sistema de

alimentação deixa de gerar energia pelo que se a tarefa não estiver terminada não ser vai possível

terminar. O software deve então configurar as frequências do sistema de forma a completar as

tarefas reais específicas e com requisitos e restrições de cada aplicação.

A utilização de frequências dispersa pelo microcontrolador permite um controlo de

granularidade mais fino devendo ser fruto de uma análise mais cuidada quer em termos de

configuração quer em termos da implementação das mesmas. Na Figura 54 pode-se visualizar o

esquema de uma possível configuração de multifrequência.

85

Figura 54 - diagrama de blocos de cross talk

Como se pode verificar, o mesmo barramento SFR é partilhado entre o microprocessador e

os periféricos e de outra forma não seria possível comunicar entre os subsistemas. Apesar de existir

apenas um master no barramento (o microprocessador) os vários periféricos podem se encontrar a

frequências diferentes de funcionamento pelo que ele terá se de adaptar a cada uma delas

aquando da comunicação com os mesmos através dos SFRs. Este instante é crítico tendo sido

utilizadas duas abordagens (estratégias) para evitar problemas estruturais e funcionais dada

possível a natureza assíncrona entre os relógios utilizados.

A primeira abordagem passa por sincronizar todos os sinais transferidos entre o

microprocessador e o elemento periférico através de um módulo conversor que funciona muito

similarmente a um tradutor. Não foi possível implementar este conversor recorrendo a técnicas

tradicionais de sincronização como a dual flopping pois a cada leitura e escrita nos registos SFR

estão em jogo uma variedade de sinais tais como o endereço e o conteúdo. A solução desenvolvida

é capaz de sincronizar domínios de frequências completamente assíncronas surgindo como uma

solução global para qualquer sincronismo que possa ser necessário para sinais de múltiplos bits.

Apresenta-se então na Figura 55 o desenho RTL que assegura parte da transferência segura de

informação.

Esta técnica baseia-se em FIFOs de duas posições baseadas em RAM dual-port permitindo

a utilização de contadores de grey para determinar se a FIFO está vazia ou cheia.

86

Figura 55 - transferência de sinais entre domínios assíncronos (retirada de [31])

Numa breve explicação, se wfull estiver a zero indicando que pode ser efetuada uma

escrita, inicia-se a mesma com winc fazendo o toggle ao valor de waddr e indicando através de

rq2_wptr que a FIFO se encontra cheia. O leitor pode então utilizar o seu próprio rinc para proceder

à leitura da FIFO e limpar a flag wfull do escritor através de wq2_rptr. Estes sinais que atravessam

diretamente entre os dois domínios de frequência devem ser sincronizados através de dois ou três

flip flops, chamado de duplo ou triplo flopping.

Sendo assim foi necessário adaptar a interface de memória para que contemplasse este

acesso especial no acesso ao endereçamento de dados. São então utilizadas lookup tables para

indicar à interface de memória quais os endereços que devem ser sujeitos a este tipo de controlo.

Na Figura 56 pode-se verificar a implementação das mesmas no caso de endereços de leitura.

A unidade de controlo gera então os sinais adequados para iniciar a transferência de dados

elevando também a flag de wait_data até a transferência terminar. Desta forma uma transferência

entre domínios pode ser encarada como uma micro-operação simplificando o processo de

alteração da unidade de controlo e provando o sucesso da aposta em micro-operações.

A Figura 57 apresenta a geração dos sinais de controlo necessários para a travessia de

dados pela interface SFR assíncrona.

87

Figura 56 - lookup table para endereços de interface SFR assíncrona

Figura 57 - sinais de controlo para interface SFR assíncrona

88

Sempre que algum registo, de fonte ou destino que faça parte da lookup table que

determina os registos de periféricos a frequência diferente, faça parte dos operandos da instrução a

ser executada, é gerado um sinal de stall para o pipeline enquanto de se aguarda pela completa

leitura ou escrita dos dados sobre outro domínio de relógio. Devido à natureza intrínseca do

barramento SFR com endereços diferentes para cada registo, cada qual responde sempre que

deteta o seu próprio endereço no barramento. Esta estratégia foi reutilizada nos SFR assíncronos

sendo utilizado um sinal de ready que aglomera todos as flags de ready dos periféricos assíncronos

após convertidos para o domínio de relógio do CPU. Desta forma, baseado na premissa de que

apenas o periférico requisitado para leitura ou escrita responderá, o stall será terminado ao detetar

um valor lógico alto da flag ready. Caso seja uma micro-operação de leitura, é colocado no

barramento de dados o valor referente ao periférico que ativou a sua flag ready. Através da

flexibilidade fornecida através de micro-operações é possível partir instruções em micro-operações

para se perder o número mínimo de ciclos de relógio aquando, por exemplo, da leitura e da escrita

simultânea em dois SFRs assíncronos.

O pacote de dados a ser transmitido é um sinal de vinte e nove bits codificado que

transporta todos os sinais do barramento SFR para uma pequena memória FIFO sendo que o

elemento recetor do pacote deve descodificá-lo por forma a obter os respetivos sinais de

barramento SFR. Foram então implementados módulos para: (1) codificação do barramento SFR

num único sinal de vinte e nove bits que é atualizado apenas quando seja necessário

sincronização, permitindo então redução de energia dinâmica; (2) descodificação de (1); (3)

esquema da Figura 55 e seus respetivos blocos; (4) codificação do conteúdo lido dos SFR e (4)

descodificação desse mesmo conteúdo para o barramento SFR.

A alteração de um periférico para suporte a multifrequência é bastante linear sendo

necessário remover as entradas relativas ao acesso SFR e adicionar o relógio do CPU, o seu próprio

relógio, e os novos sinais de controlo fornecidos pela interface de memória. Todas as ligações

relativas ao barramento SFR são preenchidas bastando para tal fazerem parte dos argumentos da

descodificação do barramento SFR proveniente da palavra codificada lida da FIFO. Na prática

basta apenas instanciar os módulos referentes à técnica da FIFO e alterar a fonte de saída relativa

ao barramento de três estados, o que é tarefa fácil para a ferramenta de integração entre o sistema

operativo e o microcontrolador, como se pode-se verificar na Figura 59.

Foi ainda estudada outra forma de contornar os problemas da comunicação entre os

domínios de frequência do microprocessador e dos periféricos podendo-se tornar bastante trivial.

89

Caso o periférico com o qual se pretende comunicar partilhe o sinal de relógio com o módulo que

gere as frequências de relógio ou caso o sinal de relógio seja derivado desse mesmo módulo é

possível resolver a comunicação sem qualquer overhead em hardware. O fluxograma da Figura 58

realça a facilidade de adaptar qualquer software para permitir comunicação com periféricos que

operem a frequências diferentes sendo apenas necessário que o hardware suporte o

funcionamento do CPU nessas mesmas frequências. Foram também desenvolvidas

implementações em C++ através de meta programação e em C através de token pasting 6

procurando-se o mínimo de overhead possível para tornar mais transparente o acesso a este tipo

de registos.

Figura 58 - fluxograma controlo SFR multifrequência

O código desenvolvido para lidar com estes acessos aos registos encontra-se em anexo.

6 Operador (##) que permite a junção de dois tokens

90

Figura 59 - suporte SFR assíncronos para periféricos múltipla frequência

91

Capítulo 4

Testes e Resultados

Durante a etapa de desenvolvimento foram realizados vários testes ao sistema que

permitem aferir sobre o funcionamento do mesmo em várias frentes: (1) resposta lógica; (2)

desempenho; (3) dissipação de potência e (4) gastos energéticos. Cada um dos quais foi

sucessivamente repetido durante toda a etapa de desenvolvimento pois apesar da

interoperabilidade entres os vários componentes do sistema, a sua natureza volátil e progressiva

coloca por vezes em causa módulos do sistema previamente testados e leva também a que novas

funcionalidades necessitem de ser testadas. É neste sentido que a reutilização de código se prova

de valor quando aliada a um RTL desenhado com princípios de encapsulamento no sentido em

que facilita o processo de teste às várias configurações possíveis do sistema.

Serão então apresentados alguns dos testes realizados, ao sistema e respetivos blocos

constituintes, esperando-se fazer acreditar do sucesso de construção do microcontrolador assim

como das suas capacidades em termos de desempenho e baixo consumo. Foram utilizados

códigos de teste em C [32] tendo outros sido desenvolvidos de acordo com a necessidade de teste.

É então utilizado o IDE IAR Embedded Workbench para a compilação de código de teste

nas linguagens C, C++ e Assembly. Este permite a configuração de vários ambientes pelo a

configuração de depuração permite visualizar os valores presentes em cada registo e posição de

memória num dado tempo sendo também possível a escolha de uma configuração que crie

ficheiros hexadecimais intel standard contendo o conteúdo de memória que deve ser carregado na

ROM. Foi então necessário desenvolver uma aplicação capaz de converter esse mesmo ficheiro

hexadecimal para um ficheiro capaz de ser convertido no conteúdo da ROM. Dada a variedade de

famílias FPGA é possível criar ficheiros do tipo IN, COE e MIF nas variantes de 8 e 32 bits por

forma a ser possível adaptar os mesmos às várias implementações possíveis do microprocessador.

92

Verificação da ISA 4.1.

O primeiro exemplo será relativo ao funcionamento correto de todas as instruções relativas

à ISA 8051 recorrendo-se a um testbench que carrega para a ROM o software que testas as

instruções exceto ACALL, LCALL, RET, RETI e MOVX. Cada instrução é submetida a um reduzido

número de testes (cerca de 3 testes por instrução) sendo todavia suficiente para se ter tornado na

primeira linha de verificação do sistema.

Figura 60 - testbench de quase totalidade das instruções

Na Figura 60 é possível verificar o teste com sucesso da quase totalidade das instruções a

serem executadas. Como se pode verificar foi criado um testbench automatizado que facilita o

processo de verificação do resultado de cada teste bastando verificar as mensagens escritas na

consola.

O próximo exemplo será relativo ao acesso à memória externa tendo sido utilizado um

código que escreve incrementalmente em duas mil e quarenta e oito posições de memória partindo

da posição inicial zero.

93

Figura 61 - estado da memória externa após teste

Como se pode verificar na Figura 61 o teste foi concluído com sucesso tendo a memória

ficado preenchida com blocos de contagem de zero até duzentos e cinquenta e cinco.

Recursos Utilizados 4.2.

Após os testes iniciais indicativos do funcionamento correto do microcontrolador são então

apresentados resultados relativos ao espaço de área ocupado pelo microcontrolador,

nomeadamente a quantidade de Slice LUTs ocupadas relativamente à arquitetura Xilinx. Em

primeiro lugar apresenta-se a configuração de um microcontrolador com 16KB de ROM interna,

2KB de XRAM interna assim como os periféricos típicos dos 8051 aliados a uma unidade de

controlo de frequência. Os resultados obtidos podem ser visualizados na Figura 62.

Figura 62 - recursos utilizados por microcontrolador numa configuração padrão

94

Como se pode verificar, a utilização total do microcontrolador situa-se nos 1603 Slice LUTs

tendo como frequência máxima alcançável 31 MHz. Tanto os recursos utilizados como a

frequência máxima dependem consideravelmente de qual o chip para o qual se pretende

programar sendo estes resultados relativamente a um low-end Spartan-6. O teste da Figura 60 foi

repetido por forma a calcular o número de ciclos de relógio necessários à sua conclusão tendo-se

obtido o valor de 2492 ciclos de relógio. Numa tentativa de comparação qualitativa, efetuou-se um

teste através do IDE Keil µVision, tendo-se obtido um tempo total de 1.982 ms. Estes dados são

indicadores de que o microcontrolador desenvolvido consegue finalizar o teste 9.5 vezes mais

rápido do que outros microcontroladores 8051 utilizando a mesma frequência de relógio. Estes

valores dependem contudo das instruções predominantemente executadas dado que umas

conseguem ser efetuadas em menos ciclos de relógio do que outras. Para uma medição mais

rigorosa seriam necessários testes reais a cada um dos chips dado que os depuradores não

conseguem implementar todas as características exóticas de uma variedade de microcontroladores.

Dissipação de Potência 4.3.

Para finalizar a comparação é necessário calcular a potência dissipada previsível sendo

utilizado o programa XPower Analyzer da Xilinx. Para que este consiga calcular a potência é

necessário proceder a uma simulação que ao invés de simular o comportamento especificado no

RTL simula os elementos sintetizados e mapeados no chip especificado sendo uma simulação

muito fiel à realidade. Os resultados obtidos, à frequência de 12.2 MHz, podem então ser

visualizados na Figura 63.

Figura 63 - gasto de potência do microcontrolador a 12.2 MHz

95

A potência média dissipada é então de 3.5 mW sendo 1.76 mW atribuídos à dissipação

estática e 1.81mW à potência dinâmica. Tal como previamente previsto a ALU é o elemento mais

consumidor de energia tendo a sua cota parte de 0.58 mW dissipados. Frisa-se contudo a forte

dependência destes valores do caminho percorrido pelo datapath sendo que, por exemplo, a

criação de um caminho alternativo para o módulo da divisão permitiu melhorar a overall do

consumo.

Na Figura 64 pode-se verificar uma melhoria de 0.11 mW em relação à medição anterior.

Figura 64 – nova medição do gasto de potência do microcontrolador a 12.2 MHz

Este facto pode ser explicado devido ao pack factor, ou seja, quando a utilização de

recursos de FPGA se aproxima do seu limite, especialmente em chips mais pequenos, a lógica é

roteada de forma adversa ao desempenho e dissipação de potência. Ainda sobre o mesmo chip

foram obtidas dissipações de 1.07 mW e 270 uW relativas as frequências de relógio de 4 MHz e 1

MHz, respetivamente.

Na Figura 65 pode-se verificar os resultados equivalentes para um dispositivo de maior

dimensão onde o pack factor não terá tanto impacto (sobre a mesma implementação) obtendo-se

melhorias em toda a gama de frequências tendo-se alcançado o valor mínimo de 230 uW.

Na Figura 66 apresenta-se a relação entre a potência dissipada e a frequência de

funcionamento de dois chips Spartan-6 tendo o 9L quantidade superior de recursos pelo que a

diferença entre ambos deve-se maioritariamente à influência do pack factor referido anteriormente.

96

Figura 65 - medição do gasto de potência do microcontrolador a 12.2 MHz num chip de dimensão de gama média

Figura 66 - gráfico potência dissipada - frequência

É ainda importante referir que os resultados obtidos podem ainda ser melhorados pois a

ferramenta XPower Analyzer não é capaz de gerar relatórios de dissipação de potência com

granularidade suficiente para permitir uma análise dos pontos críticos de dissipação. Os resultados

de dissipação estática de potência foram também omissos pois não são passíveis de

melhoramentos suficientemente mensuráveis devido à natureza de blocos FPGA. Sendo assim, a

dissipação estática dependerá do chip de FPGA escolhido para incorporar o sistema

microcontrolador.

0

1

2

3

4

5

6

7

8

0 5 10 15 20 25 30

Po

tên

cia

(mW

)

Frequência (MHz)

mW::MHz

4L

9L

97

Relativamente ao consumo de potência em modos de suspensão, foi utilizada a ferramenta

Libero SOC da Actel tendo-se mostrado como a melhor ferramenta livre para o efeito. É possível

verificar a corrente que será consumida em cada modo de suspensão.

A Figura 67 retrata a dissipação de potência e consumo de corrente no modo Idle em que

a árvore de relógio é completamente desligada permanecendo apenas a dissipação de potência

estática inerente aos recursos utilizados pelo próprio chip.

Figura 67 - dissipação de potência em modo Idle

Na Figura 68apresenta-se consumo de potência e corrente em modo sleep.

Figura 68 - dissipação de potência em modo sleep

Como se pode verificar, existe uma redução extremamente considerável devido ao corte da

alimentação VCC permanecendo apenas a alimentação encarregue de alimentar os recursos

necessários para assegurar o mantimento da informação que retrata o estado de execução atual do

microcontrolador para que o resumo para um modo ativo seja efetuado sem perder qualquer

informação dos seus registos e memória de dados associados.

98

Co-Design com o Sistema Operativo 4.4.

O trabalho cooperativo com o sistema operativo desenvolvido no mesmo projeto permitiu

também o teste de uma panóplia de instruções cuja combinação fosse mais invulgar tendo-se

detetado alguns bugs no microcontrolador. Este processo revelou-se bastante complexo pois

identificar a instrução ou instruções causadoras da incongruência de resultados entre simulação no

ambiente de compilação do código fonte do software e no ambiente de simulação do

microcontrolador implementado é semelhante à procura de “uma agulha num palheiro”. Para

melhor auxiliar este processo, o testbench utilizado para teste do sistema operativo foi embutido de

mecanismos de deteção das chamadas de rotinas internas do sistema operativo. Desta forma é

possível obter informações de tracing de execução permitindo um acompanhamento com o

debugger, por exemplo o do IAR, observando e comparando os valores da memória e registos à

procura de incongruências.

Figura 69 - mudança de frequência pelo escalonador low-power e deteção de rotinas do sistema operativo

Na Figura 69 pode-se visualizar a chamadas da rotina main do sistema operativo, assim

como várias chamadas a funções internas do compilador como __cstart_call_ctors e ?FLT_MUL.

Para atestar sobre as diferenças de desempenho entre um escalonador implementado

completamento em software e o suporte ao escalonador em hardware foi utilizado o mesmo

método referido anteriormente tendo-se atribuído ao porto zero o valor setenta e sete e oitenta e

oito em hexadecimal em etapas de execução que diferem em ambas as implementações, como se

pode verificar na figura 9.

99

Figura 70 - exemplo de teste de desempenho a função

Obtém-se então uma diferença de duzentos microssegundos no melhor caso onde a

frequência selecionável é a primeira e uma diferença de quatrocentos microssegundos para o caso

da seleção da frequência mais rápida, ou seja, a última frequência da lista (pode-se rever em

3.9.4.1). Traduzindo-se o tempo em ciclos de relógio, estando o teste a correr a 12.2 MHz, são

reduzidos de dois mil quatrocentos e quarenta a nove mil seiscentos e oitenta ciclos de relógio o

que sem dúvida contribui para o desempenho e resposta do sistema operativo dado que esta rotina

é chamada a cada tick do temporizador do sistema.

Outro elemento importante para o sistema operativo é o watchdog que pode ser utilizado

em várias camadas do sistema operativo de acordo com a sua configuração. Um dos testes

efetuados relaciona-se a utilização do watchdog para detetar tarefas que não estejam responsivas,

sendo utilizado especialmente para escalonadores preemptivos. Existe a possibilidade de o reset do

sistema ser automaticamente acoplado ao timeout do watchdog ou então deixar o processo de

decisão para o sistema operativo que pode optar simplesmente por reiniciar a tarefa. A figura xpto

representa então uma parte do registo de eventos do sistema operativo sendo detetado um reset ao

microcontrolador acionado pelo timeout do watchdog.

100

Figura 71 - registo de eventos do SO com reset por tmeout do watchdog

101

Capítulo 5

Conclusão

Esta dissertação apresenta o desenho e implementação de um microcontrolador low power

customizável da família 8051. Ao mesmo tempo faz parte de um projeto impulsionado por três

dissertações que visa a criação de um ambiente de desenvolvimento com vista a permitir ao

projetista a otimização de um sistema embebido de acordo com requisitos e restrições específicos

da aplicação alvo. O elevado grau de customização suportado pelo microcontrolador permite que a

configuração do mesmo seja estabelecida segundo modelos através de regras ontológicas de alto

nível. Assim, eliminam-se as assimetrias entre o microcontrolador e sistema operativo permitindo

que ambos sejam otimizados em uníssono fornecendo a melhor solução possível, de acordo com

as especificações fornecidas e a customização possível.

O trabalho cooperativo com o sistema operativo sugere a necessidade de adaptação de

mais periféricos ao microcontrolador para melhor se adequar aos requisitos de cada aplicação alvo.

A utilização de ferramentas EDA mais orientadas ao low power (sem licenças livres disponíveis)

permitirá também uma medição mais precisa da potência dissipada podendo-se obter melhores

resultados ao identificar com mais exatidão elementos mais dissipadores.

Resultados, Limitações e Trabalho Futuro 5.1.

Nos dias de hoje o desempenho não é mais o requisito técnico por excelência sendo

acompanhado de perto pelo baixo consumo/durabilidade energética. Este cenário é tão verdade no

mercado de eletrónica de consumo, abrangendo desde telemóveis a tablets, como em ambientes

industriais de plataformas de monitorização sem fios ou mesmo clusters de servidores.

Os resultados obtidos até ao momento são bastante encorajadores pois o microcontrolador

desenvolvido é capaz de rivalizar em ambas as frentes de desempenho e dissipação de potência

reduzida tendo-se cumprido os objetivos propostos de baixa dissipação energética. O sistema final é

bastante flexível em termos do que um microcontrolador se pode tornar para melhor se adaptar

aos requisitos e restrições da aplicação alvo. O desenvolvimento modular de que foi alvo permite

que seja facilmente expandido através de mecanismos do tipo plug&play.

102

Apesar do sucesso do trabalho desenvolvido, existem aí ainda algumas limitações que

devem ser removidas por forma a aumentar a configurabilidade do sistema, como por exemplo, as

caches sobre memórias externas de dados e de instrução devem poder ser customizadas de

acordo com o profiling da aplicação alvo seguindo técnicas power aware. Para melhorar a

dissipação de potência é também necessário utilizar ferramentas não disponíveis livremente mas

que serão necessárias para reduzir ainda mais a dissipação de potência.

Apesar de não ter constado na especificação do sistema, os depuradores por hardware são

também elementos essenciais durante o desenvolvimento de aplicações pelo que deverá ser

estudado um standard assim como formas de suportar o mesmo no ambiente de desenvolvimento

para melhor partido tomar do mesmo.

Em suma, a modularidade ao nível do RTL fornecida pela ferramenta desenvolvida no

projeto global permite com que este microcontrolador seja facilmente expandido, potenciando as

suas capacidades de se adaptar a qualquer aplicação sobre qualquer tecnologia física. Carece

todavia de testes relativamente à arquitetura ASIC, necessários para estabelecer um ponto de

comparação plausível com outras soluções presentes no mercado.

103

Apêndice A

Acesso Seguro a SFRs assíncronos

#include <ioAT89C51RD2.h>

typedef unsigned char uint8_t ;

__sfr __no_init volatile uint8_t WDTCON @ 0xa7;

__sfr __no_init uint8_t CKRL1 @ 0xD8; // it is not volatile

//Macro Helper

#define E_SAFECLK_ANY \

pop(CKRL)

#define P_SAFECLK_WDTCON \

push(CKRL); \

CKRL = (CKRL & ~0x07) | ((CKRL1 & 0x38) >> 3)

#define P_SAFECLK_P1 \

push(CKRL); \

CKRL = (CKRL & ~0x07) | ((CKRL1 & 0x7) >> 3)

#define cli() asm("push 0xA8"); \

asm("clr 0xA8.7");

#define sei() asm("pop 0xA8")

#define push(x) asm( "push " #x)

#define pop(x) asm( "pop " #x)

namespace SFRU

{

enum SFR

{

P0 = 0x80,

P1,

P2,

P3,

WDTREG = 0xa5,

WDTRST,

WDTCON

};

}

template <SFRU::SFR addr> struct SFRManage;

//Template Genérica

template <SFRU::SFR addr>

struct SFRManage {

//error

};

//Template Especifica 1

template <>

104

struct SFRManage <SFRU::P1> {

inline static uint8_t READ() {

cli();

P_SAFECLK_P1;

//tmp is optmized away

uint8_t tmp = P1;

E_SAFECLK_ANY;

cli();

return tmp;

}

inline static void WRITE(uint8_t w) {

cli();

P_SAFECLK_P1;

P1=w;

E_SAFECLK_ANY;

sei();

}

};

template <>

struct SFRManage <SFRU::WDTCON> {

inline static uint8_t READ() {

cli();

P_SAFECLK_WDTCON;

//tmp is optmized away

uint8_t tmp = WDTCON;

E_SAFECLK_ANY;

sei();

return tmp;

}

inline static void WRITE(uint8_t w) {

cli();

P_SAFECLK_WDTCON;

WDTCON=w;

E_SAFECLK_ANY;

sei();

}

};

// C version

#define SFR_READ(x,y) \

cli(); \

P_SAFECLK_##y; \

*x = y; \

E_SAFECLK_ANY; \

sei()

#define SFR_WRITE(x,y) \

cli(); \

P_SAFECLK_##y; \

y = x; \

E_SAFECLK_ANY; \

sei()

int main()

{

// C++ version

uint8_t a = SFRManage< SFRU::WDTCON>::READ();

SFRManage< SFRU::WDTCON>::WRITE(0x10);

SFRManage< SFRU::P1>::WRITE(0x13);

105

// C version

SFR_READ(&a,WDTCON);

SFR_WRITE(5,P1);

SFR_READ(&a,P1);

return a;

}

107

Apêndice B

Testbenchs de verificação ìnclude "lp805x_config.v"

//`define POST_ROUTE

module lp805x_gtb(

);

//parameter FREQ = 12000; // frequency in kHz

parameter FREQ = 12000; // frequency in kHz

//parameter FREQ = 3500; // frequency in kHz

parameter DELAY = 500000/FREQ;

reg rst,clk,int0,int1;

reg [7:0] p0_in;

wire [7:0] p0_out;

reg [15:0] counter;

ìfdef LP805X_ROM_ONCHIP

wire ea_in=1;

èlse

wire ea_in=0;

èndif

lp805x_top #(.PWMS_LEN(1)) lp805x_top_1(

.wb_rst_i(~rst),

.wb_clk_i(clk),

.int0_i(int0), .int1_i(int1),

ìfdef LP805X_PORTS

ìfdef LP805X_PORT0

.p0_i(p0_in),

.p0_o(p0_out),

èndif

èndif

.ea_in( ea_in)

);

initial

begin

clk = 0;

counter = 16'd0;

forever begin

#DELAY clk <= ~clk;

counter <= clk ? counter + 1'b1 : counter;

end

end

initial

begin

108

rst= 1'b1;

p0_in = 8'hA5;

int0 = 1'b0;

int1 = 1'b0;

// wait for 2 cycles for reset to settle

repeat(2)@(posedge clk);

rst = 1'b0;

$display("reset over!\n");

if (ea_in)

$display("Test running from internal rom!");

else

$display("Test running from external rom!");

end

// ALLmost all insn test

always @(p0_out)

begin

if ( p0_out == 8'd127)

begin

$display("Test ran successfully in: ",counter-2,"

clock cycles!");

$finish;

end

else if ( p0_out != 8'd255)

begin

$display("Test failed with exit code: ",p0_out);

$finish;

end

end

//// XRAM test

always @(p0_out)

begin

if ( p0_out == 8'd127)

begin

$display("Xram Test ran successfully!");

$finish;

end

else if ( p0_out != 8'd255)

begin

$display("Xram Test failed with exit code: ",p0_out);

$finish;

end

end

endmodule

always @(posedge clk)

if (op_cur===8'h8b) begin

if ( op2===8'h09) begin

$display("time %t => Catch ADEOS main! Nice", $time);

$finish;

end

end


109

if (op_cur===8'h8a) begin

if ( op2===8'h08) begin

$display("time %t => Catch 211A mov v0,r2", $time);

$finish;

end

end


if (op_cur===8'h12)

if ( op2===8'h26)

if ( op3===8'h0c) begin

$display("time %t => Catch pStack = new char[stacksize]", $time);´

$finish;

end

always @(addr)

if (addr===16'h20da) begin

$display("time %t => Catch 20da add!", $time);

$finish;

end


if (data_in===8'hzz) begin

$display("time %t => Z in data_in!", $time);

$finish;

end

// synthesis translate_off

always @(p0_out)

if ( p0_out == 8'h77)

begin

$display("P0=77H @ ",$time,"ns");

end

always @(p0_out)

if ( p0_out == 8'h78)

begin


end

always @(p0_out)

if ( p0_out == 8'h88)

begin


$finish;

end

// catch P0=II

always @(op_cur or imm)

if ((op_cur==8'h75) && (imm==8'h80)) begin

$display("time %t => catch P0=!!!", $time);

end

//catch a LCALL ?FLT_MUL

always @(op_cur or imm or imm2)

110

if ((op1==8'h12) && (imm==8'h02) && (imm2==8'h40)) begin

$display("time %t => catch LCALL ?FLT_MUL", $time);

end

//catch a LCALL __cstart_call_ctors


if ((op1==8'h12) && (imm==8'h26) && (imm2==8'h04)) begin

$display("time %t => catch LCALL __cstart_call_ctors", $time);

end

//catch a LCALL main


if ((op_cur==8'h12) && (imm==8'h1E) && (imm2==8'h54)) begin

$display("time %t => catch LCALL main", $time);

end

//catch a LCALL ?CALL_IND


if ((op_cur==8'h12) && (imm==8'h0A) && (imm2==8'h29)) begin

$display("time %t => catch LCALL ?CALL_IND", $time);

end

//catch a LCALL ?FUNC_ENTER_XDATA


if ((op_cur==8'h12) && (imm==8'h0A) && (imm2==8'h2B)) begin

$display("time %t => catch LCALL ?FUNC_ENTER_XDATA", $time);

end

//catch a LJMP ?FUNC_LEAVE_XDATA


if ((op_cur==8'h02) && (imm==8'h0A) && (imm2==8'h91)) begin

$display("time %t => catch LJMP ?FUNC_LEAVE_XDATA", $time);

end

//identify running task!

always @(p1_out)

if ( p1_out == 8'd0)

$display("Catch %tns => Catch TaskIdle running",$time);

else if ( p1_out == 8'd1)

$display("Catch %tns => TaskA running",$time);


$display("Catch %tns => TaskB running",$time);


$display("Catch %tns => TaskC running",$time);

//

always @(wdtov)

if ( wdtov)

$display("Watchdog Timeout!");

always @(wdt_event)

if ( wdt_event) begin

$display("Watchdog Driven Reset!");

111

repeat(5)@(posedge clk) ;

$finish;

end

// synthesis translate_on

module div_tb;

// Inputs

reg clk;

reg rst;

reg enable;

reg [7:0] src1;

reg [7:0] src2;

// Outputs

wire [7:0] des1;

wire [7:0] des2;

wire desOv;

// Instantiate the Unit Under Test (UUT)

lp805x_divide uut (

.clk(clk),

.rst(rst),

.enable(enable),

.src1(src1),

.src2(src2),

.des1(des1),

.des2(des2),

.desOv(desOv)

);

initial begin

// Initialize Inputs

clk = 0;

rst = 0;

enable = 0;

src1 = 0;

src2 = 0;

// Wait 100 ns for global reset to finish


rst=1;

src1=50;

src2=3;


enable=1;

// Add stimulus here

end

initial

begin

clk = 0;

forever #10 clk <= ~clk;

end

112

endmodule

module bufgmux_tb;

// Inputs

reg clk1;

reg clk2;

reg rst;

reg sel;

// Outputs

wire clko;

wire lg;

// Instantiate the Unit Under Test (UUT)

bufgmux_test uut (

.clk1(clk1),

.clk2(clk2),

.rst(rst),

.clko(clko),

.sel(sel),

.lg(lg)

);

initial begin

// Initialize Inputs

clk1 = 0;

clk2 = 0;

rst = 0;

sel = 0;

// Wait 100 ns for global reset to finish

#120;

sel=1;

#107

sel=0;

#53

sel=1;

#49

sel=0;

#33

sel=1;

// Add stimulus here

end

always #5 clk1 = ~clk1;

always #12 clk2 = ~clk2;

endmodule

113

Apêndice C

Formatos de Instruções 8051

8051 Instruction Set Summary Rn Register R7-R0 of the currently selected Register Bank. Data 8-bit internal data location’s address. This could be an internal Data

RAM location (0-127) or a SFR [i.e. I/O port, control register, status register, etc. (128-255)].

@Ri 8-bit Internal Data RAM location (0-255) addressed indirectly through register R1 or R0.

#data 8-bit constant included in instruction. #data16 16-bit constant included in instruction. addr16 16-bit destination address. Used by LCALL and LJMP. A branch can be

anywhere within the 64k byte Program Memory address space. addr11 11-bit destination address. Used by ACALL and AJMP. The branch will

be within the same 2k byte page of Program Memory as the first byte of the following instruction.

rel Signed (two’s component) 8-bit offset byte. Used by SJMP and all conditional jumps. Range is –128 to +127 bytes relative to first byte of the following instruction.

bit Direct Addressed bit in Internal Data RAM or Special Function Register.

Flag FlagInstruction C OV AC

Instruction C OV AC

ADD X X X CLR C OADDC X X X CPL C XSUBB X X X ANL C,bit XMUL O X ANL C,/bit XDIV O X ORL C,bit XDA X ORL C,/bit XRRC X MOV C,bit XRLC X CJNE XSETB C 1 Note that operations on SFR byte address 206 or bit addresses 209-215 (i.e. the PSW or bits in the PSW) will also affect flag settings.

Mnemonic Description Byte Cycle

Arithmetic operations ADD A,Rn Add register to accumulator 1 1 ADD A,direct Add direct byte to accumulator 2 1 ADD A,@Ri Add indirect RAM to accumulator 1 1 ADD A,#data Add immediate data to accumulator 2 1 ADDC A,Rn Add register to accumulator with carry flag 1 1 ADDC A,direct Add direct byte to A with carry flag 2 1 ADDC A,@Ri Add indirect RAM to A with carry flag 1 1 ADDC A,#data Add immediate data to A with carry flag 2 1 SUBB A,Rn Subtract register to accumulator with borrow 1 1 SUBB A,direct Subtract direct byte to A with carry borrow 2 1 SUBB A,@Ri Subtract indirect RAM to A with carry borrow 1 1 SUBB A,#data Subtract immediate data to A with carry borrow 2 1 INC A Increment accumulator 1 1INC Rn Increment register 1 1INC direct Increment direct byte 2 1INC @Ri Increment indirect RAM 1 1 DEC A Decrement accumulator 1 1DEC Rn Decrement register 1 1DEC direct Decrement direct byte 2 1DEC @Ri Decrement indirect RAM 1 1 INC DPTR Increment data pointer 1 2MUL AB Multiply A and B -> [B hi]:[A lo] 1 4 DIV AB Divide A by B -> A=result, B=remainder 1 4 DA A Decimal adjust accumulator 1 1CLR A Clear accumulator 1 1


CPL A Complement accumulator 1 1RL A Rotate accumulator left 1 1 RLC A Rotate accumulator left through carry 1 1 RR A Rotate accumulator right 1 1 RRC A Rotate accumulator right through carry 1 1 SWAP A Swap nibbles within the accumulator 1 1

Logic operations ANL A,Rn AND register to accumulator 1 1 ANL A,direct AND direct byte to accumulator 2 1 ANL A,@Ri AND indirect RAM to accumulator 1 1 ANL A,#data AND immediate data to accumulator 2 1 ANL direct,A AND accumulator to direct byte 2 1 ANL direct,#data AND immediate data to direct byte 3 2 ORL A,Rn OR register to accumulator 1 1 ORL A,direct OR direct byte to accumulator 2 1 ORL A,@Ri OR indirect RAM to accumulator 1 1 ORL A,#data OR immediate data to accumulator 2 1 ORL direct,A OR accumulator to direct byte 2 1 ORL direct,#data OR immediate data to direct byte 3 2 XRL A,Rn Exclusive OR register to accumulator 1 1 XRL A,direct Exclusive OR direct byte to accumulator 2 1 XRL A,@Ri Exclusive OR indirect RAM to accumulator 1 1 XRL A,#data Exclusive OR immediate data to accumulator 2 1 XRL direct,A Exclusive OR accumulator to direct byte 2 1 XRL direct,#data Exclusive OR immediate data to direct byte 3 2

Boolean variable manipulation CLR C Clear carry flag 1 1 CLR bit Clear direct bit 2 1 SETB C Set carry flag 1 1 SETB bit Set direct bit 2 1CPL C Complement carry flag 1 1 CPL bit Complement direct bit 2 1ANL C,bit AND direct bit to carry flag 2 2 ANL C,/bit AND complement of direct bit to carry 2 2 ORL C,bit OR direct bit to carry flag 2 2 ORL C,/bit OR complement of direct bit to carry 2 2 MOV C,bit Move direct bit to carry flag 2 1 MOV bit,C Move carry flag to direct bit 2 2

Program and machine control ACALL addr11 Absolute subroutine call 2 2 LCALL addr16 Long subroutine call 3 2 RET Return from subroutine 1 2RETI Return from interrupt 1 2AJMP addr11 Absolute jump 2 2 LJMP addr16 Long jump 3 2SJMP rel Short jump (relative address) 2 2 JMP @A+DPTR Jump indirect relative to the DPTR 1 2 JZ rel Jump if accumulator is zero 2 2 JNZ rel Jump if accumulator is not zero 2 2 JC rel Jump if carry flag is set 2 2 JNC rel Jump if carry flag is not set 2 2 JB bit,rel Jump if bit is set 3 2 JNB bit,rel Jump if bit is not set 3 2 JBC bit,rel Jump if direct bit is set and clear bit 3 2 CJNE A,direct,rel Compare direct byte to A and jump if not equal 3 2


CJNE A,#data,rel Compare immediate to A and jump if not equal 3 2 CJNE Rn,#data,rel Compare immed. to reg. and jump if not equal 3 2 CJNE @Rn,#data,rel Compare immed. to ind. and jump if not equal 3 2 DJNZ Rn,rel Decrement register and jump in not zero 2 2 DJNZ direct,rel Decrement direct byte and jump in not zero 3 2 NOP No operation 1 1

Data transfer MOV A,Rn Move register to accumulator 1 1 MOV A,direct*) Move direct byte to accumulator 2 1 MOV A,@Ri Move indirect RAM to accumulator 1 1 MOV A,#data Move immediate data to accumulator 2 1 MOV Rn,A Move accumulator to register 1 1 MOV Rn,direct Move direct byte to register 2 2 MOV Rn,#data Move immediate data to register 2 1 MOV direct,A Move accumulator to direct byte 2 1 MOV direct,Rn Move register to direct byte 2 2 MOV direct,direct Move direct byte to direct byte 3 2 MOV direct,@Ri Move indirect RAM to direct byte 2 2 MOV direct,#data Move immediate data to direct byte 3 2 MOV @Ri,A Move accumulator to indirect RAM 1 1 MOV @Ri,direct Move direct byte to indirect RAM 2 2 MOV @Ri,#data Move immediate data to indirect RAM 2 1 MOV DPTR,#data16 Load data pointer with a 16-bit constant 3 2 MOVC A,@A+DPTR Move code byte relative to DPTR to accumulator 1 2 MOVC A,@A+PC Move code byte relative to PC to accumulator 1 2 MOVX A,@Ri Move external RAM (8-bit addr.) to A 1 2 MOVX A,@DPTR Move external RAM (16-bit addr.) to A 1 2 MOVX @Ri,A Move A to external RAM (8-bit addr.) 1 2 MOVX @DPTR,A Move A to external RAM (16-bit addr.) 1 2 PUSH direct Push direct byte onto stack 2 2 POP direct Pop direct byte from stack 2 2 XCH A,Rn Exchange register to accumulator 1 1 XCH A,direct Exchange direct byte to accumulator 2 1 XCH A,@Ri Exchange indirect RAM to accumulator 1 1 XCHD A,@Ri Exchange low-order nibble indir. RAM with A 1 1 *) MOV A,ACC is not a valid instruction

jne A,#data,@ (jump if A ! = data)

cjne A,#data,@

je A, #data,@ (jump if A == data)

add A,#low(−data) or cjne A,#(data),ne jz @ jmp @ ne: ...

ja, jnbe A,#data,@ (jump if A > data)

add A,#low(−data−1) or cjne A,#(data+1),ne jc @ ne: jnc @

jae, jnb A,#data,@ (jump if A >= data)

add A,#low(−data) or cjne A,#(data),ne jc @ ne: jnc @

jb, jnae A,#data,@ (jump if A < data)

add A,#low,(−data) or cjne A,#(data),ne jnc @ ne: jc @

jbe, jna A,#data,@ (jump if A <= data)

add A,#low(−data−1) or cjne A,#(data+1),ne jnc @ ne: jc @

switch A <,==,> #data (no A modification)

cjne A,#data,ne ... ; execute code if A==data ne: jc is_below ; jump if A<data jnc is_above ; jump if A>data or exec. code

EEnnjjooyy IItt!! MMaatteess This paper was created by Štěpán Matějka alias Mates for anybody who needs it. Mates, Prague – Czech Republic 1998,2002.

8051 Instruction Set Table

.0Mates(c)1995,2002 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F0123456789ABCDEF

@R0 @R1 R0 R1 R2 R3 R4 R5 R6 R7

INC

DEC

A8 ..... address 8 bitsA16 ... address 16 bits

AR .... relative address 8 bitsBIT ... bit's address

D ....... data 8 bitsD16 ... data 16 bits

2 2c 3

LJMP A16

15 1c 1

INC R714 1c 1

INC R613 1c 1

INC R512 1c 1

INC R428 1c 1

DEC R429 1c 1

DEC R530 1c 1

DEC R631 1c 1

DEC R744 1c 1

ADD A,R445 1c 1

ADD A,R546 1c 1

ADD A,R647 1c 1

ADD A,R760 1c 1

76 1c 1

ORL A,R477 1c 1

ORL A,R578 1c 1

ORL A,R679 1c 1

ORL A,R792 1c 1

ANL A,R493 1c 1

ANL A,R594 1c 1

ANL A,R695 1c 1

ANL A,R7108 1c 1

XRL A,R4109 1c 1

XRL A,R5110 1c 1

XRL A,R6111 1c 1

XRL A,R7124 1c 2

MOV R4,#D

140 2c 2

MOV A8,R4

172 2c 2

MOV R4,A8

204 1c 1

XCH A,R4

236 1c 1

MOV A,R4252 1c 1

MOV R4,A

1 2c 2

AJMP 0A8

0 1c 1

NOP17 2c 2

ACALL 0A8

16 2c 3

JBC BIT,AR

32 2c 3

JB BIT,AR

61 1c 1 62 1c 1 63 1c 1

ADD

ADDC

ORL

ANL

XRL

MOV

MOV

SUBB

MOV

CJNE

XCH

DJNZ

MOV

MOV

156 1c 1

188 2c 3

220 2c 2

237 1c 1

MOV A,R5253 1c 1

MOV R5,A

221 2c 2

238 1c 1

MOV A,R6254 1c 1

MOV R6,A

222 2c 2

239 1c 1

MOV A,R7255 1c 1

MOV R7,A

223 2c 2

173 2c 2

MOV R5,A8

205 1c 1

XCH A,R5

189 2c 3

175 2c 2

MOV R7,A8

207 1c 1

XCH A,R7

191 2c 3

174 2c 2

MOV R6,A8

206 1c 1

XCH A,R6

190 2c 3

127 1c 2

MOV R7,#D

143 2c 2

MOV A8,R7159 1c 1

126 1c 2

MOV R6,#D

142 2c 2

MOV A8,R6158 1c 1

125 1c 2

MOV R5,#D

141 2c 2

MOV A8,R5157 1c 1

48 2c 3

JNB BIT,AR

64 2c 2

JC AR

80 2c 2

JNC AR

96 2c 2

JZ AR

112 2c 2

JNZ AR

128 2c 2

SJMP AR

33 2c 2

AJMP 1A8

49 2c 2

ACALL 1A8

65 2c 2

AJMP 2A8

81 2c 2

ACALL 2A8

97 2c 2

AJMP 3A8

113 2c 2

ACALL 3A8

129 2c 2

AJMP 4A8

145 2c 2

ACALL 4A8

161 2c 2

AJMP 5A8

177 2c 2

ACALL 5A8

193 2c 2

AJMP 6A8

209 2c 2

ACALL 6A8

225 2c 2

AJMP 7A8

241 2c 2

ACALL 7A8

18 2c 3

LCALL A16

34 2c 1

RET50 2c 1

RETI66 1c 2

ORL A8,A82 1c 2

ANL A8,A98 1c 2

XRL A8,A

3 1c 1

RR A

35 1c 1

RL A

19 1c 1

RRC A

51 1c 1

RLC A

4 1c 1

INC A20 1c 1

DEC A

5 1c 1

INC A8

21 1c 1

DEC A8

36 1c 2

ADD A,#D

37 1c 2

ADD A,A8

52 1c 2

ADDC A,#D

53 1c 2

ADDC A,A8

67 1c 3

ORL A8,#D

83 1c 3

ANL A8,#D

99 1c 3

XRL A8,#D

68 1c 2

ORL A,#D

84 1c 2

ANL A,#D

100 1c 2

XRL A,#D

69 1c 2

ORL A,A8

85 1c 2

ANL A,A8

101 1c 2

XRL A,A8

6 1c 1

INC @R022 1c 1

DEC @R0

7 1c 1

INC @R123 1c 1

DEC @R1

8 1c 1

INC R024 1c 1

DEC R0

9 1c 1

INC R125 1c 1

DEC R1

10 1c 1

INC R226 1c 1

DEC R2

11 1c 1

INC R327 1c 1

DEC R343 1c 1

ADD A,R359 1c 1

42 1c 1

ADD A,R258 1c 1

41 1c 1

ADD A,R157 1c 1

40 1c 1

ADD A,R056 1c 1

38 1c 1 39 1c 1

54 1c 1 55 1c 1

70 1c 1 71 1c 1

86 1c 1 87 1c 1

102 1c 1 103 1c 1

72 1c 1

ORL A,R088 1c 1

ANL A,R0104 1c 1

XRL A,R0

73 1c 1

ORL A,R189 1c 1

ANL A,R1105 1c 1

XRL A,R1

74 1c 1

ORL A,R290 1c 1

ANL A,R2106 1c 1

XRL A,R2

75 1c 1

ORL A,R391 1c 1

ANL A,R3107 1c 1

XRL A,R3114 2c 2

ORL C,BIT

130 2c 2

ANL C,BIT

146 2c 2

MOV BIT,C162 1c 2

MOV C,BIT

178 1c 2

CPL BIT

179 1c 1

CPL C194 1c 2

CLR BIT

195 1c 1

CLR C210 1c 2

SETB BIT

211 1c 1

SETB C

163 2c 1

INC DPTR164 4c 1

MUL AB

132 4c 1

DIV AB

196 1c 1

SWAP A212 1c 1

DA A228 1c 1

CLR A244 1c 1

CPL A

229 1c 2

MOV A,A8

245 1c 2

MOV A8,A

232 1c 1

MOV A,R0248 1c 1

MOV R0,A

235 1c 1

MOV A,R3251 1c 1

MOV R3,A

233 1c 1

MOV A,R1249 1c 1

MOV R1,A

234 1c 1

MOV A,R2250 1c 1

MOV R2,A240 2c 1 242 2c 1 243 2c 1

226 2c 1 227 2c 1224 2c 1

208 2c 2

POP A8

192 2c 2

PUSH A8

176 2c 2

ANL C,BIT

208 2c 2

ORL C,BIT

144 2c 3

115 2c 1

131 2c 1

147 2c 1 148 1c 2

SUBB A,#D

116 1c 2

MOV A,#D

230 1c 1 231 1c 1

246 1c 1 247 1c 1

117 2c 3

MOV A8,#D

133 2c 3

MOV A8,A8

149 1c 2

SUBB A,A8

165

180 2c 3

197 1c 2

XCH A,A8

203 1c 1

XCH A,R3202 1c 1

XCH A,R2201 1c 1

XCH A,R1200 1c 1

XCH A,R0

168 2c 2

MOV R0,A8

169 2c 2

MOV R1,A8

170 2c 2

MOV R2,A8

171 2c 2

MOV R3,A8

136 2c 2

MOV A8,R0137 2c 2

MOV A8,R1138 2c 2

MOV A8,R2139 2c 2

MOV A8,R3

120 1c 2

MOV R0,#D

121 1c 2

MOV R1,#D

122 1c 2

MOV R2,#D

123 2c 2

MOV R3,#D

213 2c 3

152 1c 1 153 1c 1 154 1c 1 155 1c 1

219 2c 2218 2c 2217 2c 2216 2c 2215 1c 1214 1c 1

198 1c 1 199 1c 1

151 1c 1150 1c 1

181 2c 3 182 2c 3 183 2c 3 187 2c 3186 2c 3184 2c 3 185 2c 3

166 2c 2 167 2c 2

134 2c 2 135 2c 2

118 1c 2 119 1c 2

0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

8051 Instruction Set Table

.0Mates(c)1995,2002 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F0123456789ABCDEF

@R0 @R1 R0 R1 R2 R3 R4 R5 R6 R7

INC

DEC

A8 ..... address 8 bitsA16 ... address 16 bits

AR .... relative address 8 bitsBIT ... bit's address

D ....... data 8 bitsD16 ... data 16 bits

2 2c 3

LJMP A16

15 1c 1

INC R714 1c 1

INC R613 1c 1

INC R512 1c 1

INC R428 1c 1

DEC R429 1c 1

DEC R530 1c 1

DEC R631 1c 1

DEC R744 1c 1

ADD A,R445 1c 1

ADD A,R546 1c 1

ADD A,R647 1c 1

ADD A,R760 1c 1

76 1c 1

ORL A,R477 1c 1

ORL A,R578 1c 1

ORL A,R679 1c 1

ORL A,R792 1c 1

ANL A,R493 1c 1

ANL A,R594 1c 1

ANL A,R695 1c 1

ANL A,R7108 1c 1

XRL A,R4109 1c 1

XRL A,R5110 1c 1

XRL A,R6111 1c 1

XRL A,R7124 1c 2

MOV R4,#D

140 2c 2

MOV A8,R4

172 2c 2

MOV R4,A8

204 1c 1

XCH A,R4

236 1c 1

MOV A,R4252 1c 1

MOV R4,A

1 2c 2

AJMP 0A8

0 1c 1

NOP17 2c 2

ACALL 0A8

16 2c 3

JBC BIT,AR

32 2c 3

JB BIT,AR

61 1c 1 62 1c 1 63 1c 1

ADD

ADDC

ORL

ANL

XRL

MOV

MOV

SUBB

MOV

CJNE

XCH

DJNZ

MOV

MOV

156 1c 1

188 2c 3

220 2c 2

237 1c 1

MOV A,R5253 1c 1

MOV R5,A

221 2c 2

238 1c 1

MOV A,R6254 1c 1

MOV R6,A

222 2c 2

239 1c 1

MOV A,R7255 1c 1

MOV R7,A

223 2c 2

173 2c 2

MOV R5,A8

205 1c 1

XCH A,R5

189 2c 3

175 2c 2

MOV R7,A8

207 1c 1

XCH A,R7

191 2c 3

174 2c 2

MOV R6,A8

206 1c 1

XCH A,R6

190 2c 3

127 1c 2

MOV R7,#D

143 2c 2

MOV A8,R7159 1c 1

126 1c 2

MOV R6,#D

142 2c 2

MOV A8,R6158 1c 1

125 1c 2

MOV R5,#D

141 2c 2

MOV A8,R5157 1c 1

48 2c 3

JNB BIT,AR

64 2c 2

JC AR

80 2c 2

JNC AR

96 2c 2

JZ AR

112 2c 2

JNZ AR

128 2c 2

SJMP AR

33 2c 2

AJMP 1A8

49 2c 2

ACALL 1A8

65 2c 2

AJMP 2A8

81 2c 2

ACALL 2A8

97 2c 2

AJMP 3A8

113 2c 2

ACALL 3A8

129 2c 2

AJMP 4A8

145 2c 2

ACALL 4A8

161 2c 2

AJMP 5A8

177 2c 2

ACALL 5A8

193 2c 2

AJMP 6A8

209 2c 2

ACALL 6A8

225 2c 2

AJMP 7A8

241 2c 2

ACALL 7A8

18 2c 3

LCALL A16

34 2c 1

RET50 2c 1

RETI66 1c 2

ORL A8,A82 1c 2

ANL A8,A98 1c 2

XRL A8,A

3 1c 1

RR A

35 1c 1

RL A

19 1c 1

RRC A

51 1c 1

RLC A

4 1c 1

INC A20 1c 1

DEC A

5 1c 1

INC A8

21 1c 1

DEC A8

36 1c 2

ADD A,#D

37 1c 2

ADD A,A8

52 1c 2

ADDC A,#D

53 1c 2

ADDC A,A8

67 1c 3

ORL A8,#D

83 1c 3

ANL A8,#D

99 1c 3

XRL A8,#D

68 1c 2

ORL A,#D

84 1c 2

ANL A,#D

100 1c 2

XRL A,#D

69 1c 2

ORL A,A8

85 1c 2

ANL A,A8

101 1c 2

XRL A,A8

6 1c 1

INC @R022 1c 1

DEC @R0

7 1c 1

INC @R123 1c 1

DEC @R1

8 1c 1

INC R024 1c 1

DEC R0

9 1c 1

INC R125 1c 1

DEC R1

10 1c 1

INC R226 1c 1

DEC R2

11 1c 1

INC R327 1c 1

DEC R343 1c 1

ADD A,R359 1c 1

42 1c 1

ADD A,R258 1c 1

41 1c 1

ADD A,R157 1c 1

40 1c 1

ADD A,R056 1c 1

38 1c 1 39 1c 1

54 1c 1 55 1c 1

70 1c 1 71 1c 1

86 1c 1 87 1c 1

102 1c 1 103 1c 1

72 1c 1

ORL A,R088 1c 1

ANL A,R0104 1c 1

XRL A,R0

73 1c 1

ORL A,R189 1c 1

ANL A,R1105 1c 1

XRL A,R1

74 1c 1

ORL A,R290 1c 1

ANL A,R2106 1c 1

XRL A,R2

75 1c 1

ORL A,R391 1c 1

ANL A,R3107 1c 1

XRL A,R3114 2c 2

ORL C,BIT

130 2c 2

ANL C,BIT

146 2c 2

MOV BIT,C162 1c 2

MOV C,BIT

178 1c 2

CPL BIT

179 1c 1

CPL C194 1c 2

CLR BIT

195 1c 1

CLR C210 1c 2

SETB BIT

211 1c 1

SETB C

163 2c 1

INC DPTR164 4c 1

MUL AB

132 4c 1

DIV AB

196 1c 1

SWAP A212 1c 1

DA A228 1c 1

CLR A244 1c 1

CPL A

229 1c 2

MOV A,A8

245 1c 2

MOV A8,A

232 1c 1

MOV A,R0248 1c 1

MOV R0,A

235 1c 1

MOV A,R3251 1c 1

MOV R3,A

233 1c 1

MOV A,R1249 1c 1

MOV R1,A

234 1c 1

MOV A,R2250 1c 1

MOV R2,A240 2c 1 242 2c 1 243 2c 1

226 2c 1 227 2c 1224 2c 1

208 2c 2

POP A8

192 2c 2

PUSH A8

176 2c 2

ANL C,BIT

208 2c 2

ORL C,BIT

144 2c 3

115 2c 1

131 2c 1

147 2c 1 148 1c 2

SUBB A,#D

116 1c 2

MOV A,#D

230 1c 1 231 1c 1

246 1c 1 247 1c 1

117 2c 3

MOV A8,#D

133 2c 3

MOV A8,A8

149 1c 2

SUBB A,A8

165

180 2c 3

197 1c 2

XCH A,A8

203 1c 1

XCH A,R3202 1c 1

XCH A,R2201 1c 1

XCH A,R1200 1c 1

XCH A,R0

168 2c 2

MOV R0,A8

169 2c 2

MOV R1,A8

170 2c 2

MOV R2,A8

171 2c 2

MOV R3,A8

136 2c 2

MOV A8,R0137 2c 2

MOV A8,R1138 2c 2

MOV A8,R2139 2c 2

MOV A8,R3

120 1c 2

MOV R0,#D

121 1c 2

MOV R1,#D

122 1c 2

MOV R2,#D

123 2c 2

MOV R3,#D

213 2c 3

152 1c 1 153 1c 1 154 1c 1 155 1c 1

219 2c 2218 2c 2217 2c 2216 2c 2215 1c 1214 1c 1

198 1c 1 199 1c 1

151 1c 1150 1c 1

181 2c 3 182 2c 3 183 2c 3 187 2c 3186 2c 3184 2c 3 185 2c 3

166 2c 2 167 2c 2

134 2c 2 135 2c 2

118 1c 2 119 1c 2

0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

Code Cycles Bytes

INSTRUCTION

117

Bibliografia

[

1]

Masaru Sugai, Kôichi Nishimura, Kazuya Takamatsu, and Takamasa Fujinaga, "Low

Power Consumption Microcontrollers and Their Applications," Hitachi Review, vol. 48, 1999.

[

2]

S. Tsasakou et al., "Hardware-software co-design of embedded systems using

CoWare's N2C methodology for application development," Electronics, Circuits and Systems,

1999. Proceedings of ICECS '99. The 6th IEEE International Conference on, vol. 1, no.

CoWare's N2C methodology;DECT protocol stack;application development;baseband

processor;co-design tasks;co-simulation problem;embedded systems;hardware-software co-

design;high-level system modeling;interface generation;medium access layer;mobile phone;, pp.

59-62, 1999.

[

3]

V. Stuikys, G. Ziberkas, R. Damasevicius, and G. Majauskas, "Two approaches for

developing generic components in VHDL," Design, Automation and Test in Europe, 2001.

Conference and Exhibition 2001. Proceedings, no. Open PROMOL;VHDL abstractions;external

scripting language;generic components;one-language approach;pure VHDL;two-language

approach;hardware description languages;logic CAD;software libraries;, 2001.

[

4]

Vytautas Štuikys, Robertas Damaševičius, and Giedrius Ziberkas, "Open PROMOL: An

Experimental Language for Target Program Modification".

[

5]

Michael Keating, David Flynn, Robert Aitken, Alan Gibbons, and Kaijian Shi, Low Power

Methodology Manual.: Springer.

[

6]

T Kanter, "An open service architecture for adaptive personal mobile communication,"

Personal Communications, IEEE, vol. 8, no. 3GPP;4G mobile communication;WLAN

extensions;adaptive personal mobile communication;application prototypes;gigabit Ethernet

network;heterogeneous wireless infrastructure;multimedia devices;open service

architecture;urban wireless testbed;wireless Internet, pp. 8-17, Dec 2001.

[

7]

SCALOPES. [Online]. http://www.scalopes.eu/index.html

http://www.scalopes.eu/index.html

118

[

8]

ASAM. [Online]. http://www.asam-project.org/

[

9]

S.M.S. Kang, "Elements of low power design for integrated systems," Low Power

Electronics and Design, 2003. ISLPED '03. Proceedings of the 2003 International Symposium

on, no. CMOS VLSI; circuit level; deep sub-100 nm technologies; gate oxide thickness scaling

down; heat dissipation; integrated systems; leakage control; logic level; low power design;

portable systems; power consumption; power dissipation sources; system level; , pp. 205-210,

Agosto 2003.

[

10]

Ricardo E. Gonzalez, LOW-POWER PROCESSOR DESIGN, 1997.

[

11]

Steve Kilts, Advanced FPGA Design.: Wiley-Interscience.

[

12]

Keshava Murali. Low Power Techniques. [Online]. http://asic-

soc.blogspot.com/2010/06/low-power-techniques-presentation.html

[

13]

Atmel lowpower 8051 mcu. [Online].

http://www.atmel.com/products/mcu8051/default.asp?category_id=163&family_id=604&sou

rce=global_nav

[

14]

Freescale lowpower mcu. [Online].

www.freescale.com/files/microcontrollers/doc/brochure/BRLWPWR.pdf

[

15]

Silabs lowpower 8051 mcu. [Online].

www.silabs.com/products/mcu/lowpower/Pages/default.aspx

[

16]

Kok-Leong Chang and Bah-Hwee Gwee, "A low-energy low-voltage asynchronous 8051

microcontroller core," in Circuits and Systems, 2006. ISCAS 2006. Proceedings. 2006 IEEE

International Symposium on, 2006.

[ Je-Hoon Lee, Young Hwan Kim, and Kyoung-Rok Cho, "A Low-Power Implementation

http://www.asam-project.org/

http://asic-soc.blogspot.com/2010/06/low-power-techniques-presentation.html

http://asic-soc.blogspot.com/2010/06/low-power-techniques-presentation.html

http://www.atmel.com/products/mcu8051/default.asp?category_id=163&family_id=604&source=global_nav

http://www.atmel.com/products/mcu8051/default.asp?category_id=163&family_id=604&source=global_nav

www.freescale.com/files/microcontrollers/doc/brochure/BRLWPWR.pdf

www.silabs.com/products/mcu/lowpower/Pages/default.aspx

119

17] of Asynchronous 8051 Employing Adaptive Pipeline Structure," Circuits and Systems II: Express

Briefs, IEEE Transactions on, vol. 55, no.

[

18]

Chao Xue, Xiang Cheng, Yang Guo, and Yong Lian, "The design of a sub-nanojoule

asynchronous 8051 with interface to external commercial memory," ASIC, 2009. ASICON '09.

IEEE 8th International Conference on, no. asynchronous 8051 microcontroller;dual-rail four-

phase protocol;external memory interface;internal asynchronous RAM;internal counters;memory

size 128 Byte;serial port;size 0.35 mum;voltage 1.0 V;microcontrollers;random-access storage;,

pp. 427-430, Outubro 2009.

[

19]

Information Technology Encyclopedia and Learning Center. [Online].

http://whatis.techtarget.com/definition/0,sid9_gci759468,00.html

[

20]

Sakina Rangoonwala, A Verilog 8051 Soft Core for FPGA Applications, 2009.

[

21]

R8051XC2 High-Performance, Configurable, 8051-Compatible, 8-bit Microcontroller

Core. [Online]. http://www.cast-inc.com/ip-cores/8051s/r8051xc2/index.html

[

22]

DP 8051. [Online]. http://www.hitechglobal.com/ipcores/dp8051.htm

[

23]

Tiny 8051. [Online]. http://www.cast-inc.com/ip-cores/8051s/t8051/index.html

[

24]

F. Iozzi, S. Saponara, A.J. Morello, and L. Fanucci, "8051 CPU core optimization for

low power at register transfer level," Research in Microelectronics and Electronics, 2005 PhD,

vol. 2, pp. 178-181, Julho 2005.

[

25]

Vitor Veiga, "Ambiente Integrado de Desenvolvimento para Sistema Operativo Tempo-

Real," Universidade do Minho, Guimarães, Dissertação de Mestrado 2012.

[

26]

(2012) 8051 Instruction Set Manual. [Online].

http://www.keil.com/support/man/docs/is51/

http://whatis.techtarget.com/definition/0,,sid9_gci759468,00.html

http://www.cast-inc.com/ip-cores/8051s/r8051xc2/index.html

http://www.hitechglobal.com/ipcores/dp8051.htm

http://www.cast-inc.com/ip-cores/8051s/t8051/index.html

http://www.keil.com/support/man/docs/is51/

120

[

27]

G. Sutter, E. Todorovich, S. Lopez-Buedo, and E. Boemo. Low-Power FSMs in FPGA:

Encoding Alternatives.

[

28]

Motorola Thomas Tkacik. A Hardware Random Number Generator.

[

29]

(2012) Xilinx UG382 Spartan-6 FPGA Clocking Resources User Guide. [Online].

http://www.xilinx.com/support/documentation/user_guides/ug382.pdf

[

30]

(2012) Low-Power Modes in Actel ProASIC3/E and ProASIC3 nano FPGAs. [Online].

http://www.actel.com/documents/PA3_E_LowPower_HBs.pdf

[

31]

Cliff Cummings. (2012) Sunburst Design. [Online]. http://www.sunburst-

design.com/papers/

[

32]

University of California. (2012) Dalton 8051. [Online].

http://www.cs.ucr.edu/~dalton/i8051/

[

33]

Jennifer Stephenson. Design Guidelines for Optimal Results in FPGAs. Documento.

[Online]. www.altera.com/literature/cp/fpgas-optimal-results-396.pdf

[

34]

Gated Clock According to Altera Standard Scheme. [Online].

quartushelp.altera.com/9.1/mergedProjects/verify/da/comp_file_rules_clock.htm

[

35]

Qing Wu, Massoud Pedram, and Xunwei Wu, "Clock-Gating and Its Application to Low

Power Design," IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS, vol. 47, no. Clock gating,

CMOS, logic, low power, sequential circuit., pp. 415-420, Março 2000.

[

36]

Oregano 8051 IP Core. [Online]. http://www.oreganosystems.at/?page_id=96

[

37]

"Scripting Language Open PROMOL and its Processor," INFORMATICA, 2000,

Dezembro 1999.

http://www.xilinx.com/support/documentation/user_guides/ug382.pdf

http://www.actel.com/documents/PA3_E_LowPower_HBs.pdf

http://www.sunburst-design.com/papers/

http://www.sunburst-design.com/papers/

http://www.cs.ucr.edu/~dalton/i8051/

www.altera.com/literature/cp/fpgas-optimal-results-396.pdf

quartushelp.altera.com/9.1/mergedProjects/verify/da/comp_file_rules_clock.htm

http://www.oreganosystems.at/?page_id=96

tiago emanuel lobo de macedo freitas castro

Documents