modelagem do pic 16f84 para projeto de sistemas …

Gabriel Renaldo Laureano

Modelagem do PIC 16F84 para Projeto de

Sistemas Embutidos Baseados em

Micro-controlador

Florianopolis – SC

2005


Modelagem do PIC 16F84 para Projeto de

Sistemas Embutidos Baseados em

Micro-controlador

Monografia apresentada ao programa deBacharelado em Ciencias da Computacaoda Universidade Federal de Santa Catarinacomo requisito parcial para obtencao do graude Bacharel em Ciencias da Computacao.

Orientador: Luiz Claudio Villar dos Santos

Universidade Federal de Santa CatarinaCentro Tecnologico

Florianopolis – SC

2005

Monografia de graduacao sob o tıtulo Modelagem do PIC 16F84 para Projeto de Siste-

mas Embutidos Baseados em Micro-controlador, defendida por Gabriel Renaldo Laureano

e aprovada em 02 de junho de 2005, em Florianopolis, Santa Catarina, pela banca exa-

minadora constituıda pelos professores:

Prof. Dr. Luiz Claudio Villar dos SantosOrientador

Universidade Federal de Santa Catarina

Prof. Dr. Luiz Fernando FriedrichUniversidade Federal de Santa Catarina

Prof. Dr. Olinto Jose Varela FurtadoUniversidade Federal de Santa Catarina

“Computer science is no more about computers

than astronomy is about telescopes.”

Edsger Dijkstra

Sumario

Lista de Figuras

Lista de Tabelas

Resumo

1 Introducao p. 7

2 O Micro-controlador PIC p. 9

2.1 Conjunto de instrucoes do PIC . . . . . . . . . . . . . . . . . . . . . . p. 9

2.2 O Registrador de status . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10

2.3 Enderecamento indireto . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11

3 Modelagem Funcional p. 14

3.1 A linguagem de descricao de arquiteturas adotada . . . . . . . . . . . . p. 14

3.2 Modelagem puramente funcional . . . . . . . . . . . . . . . . . . . . . . p. 15

3.3 Modelagem funcional com precisao de ciclos . . . . . . . . . . . . . . . p. 16

3.3.1 Datapath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

3.3.2 Estrutura do modelo . . . . . . . . . . . . . . . . . . . . . . . . p. 18

3.3.3 Hazards de controle . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

3.3.4 Hazards de dados . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

4 Resultados Experimentais p. 23

4.1 Benchmarks e configuracao experimental . . . . . . . . . . . . . . . . . p. 23

4.2 Validacao dos modelos . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

4.2.1 Testes unitarios . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24

4.2.2 Testes de integracao . . . . . . . . . . . . . . . . . . . . . . . . p. 24

4.2.3 Testes de regressao . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

4.3 Comparacao com modelo congenere . . . . . . . . . . . . . . . . . . . . p. 25

4.4 Resultados para o modelo puramente funcional . . . . . . . . . . . . . . p. 27

4.5 Resultados para o modelo com precisao de ciclos . . . . . . . . . . . . . p. 28

5 Conclusoes e Trabalhos Futuros p. 29

5.1 Produtos de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29

Referencias p. 31

Apendice A -- Codigo Fonte dos Modelos p. 33

A.1 constants.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

A.2 pic16F84.ac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37

A.3 pic16F84 isa.ac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38

A.4 pic16F84-isa.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43

A.5 pic16F84 ca.ac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67

A.6 pic16F84 ca isa.ac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68

A.7 pic16F84 ca-isa.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 74

Apendice B -- Artigo p. 111

Lista de Figuras

1 Enderecamento indireto de instrucoes . . . . . . . . . . . . . . . . . . . p. 11

2 Enderecamento indireto de dados . . . . . . . . . . . . . . . . . . . . . p. 12

3 Descricao da arquitetura do PIC 16F84 . . . . . . . . . . . . . . . . . . p. 15

4 Descricao da arquitetura do conjunto de instrucoes . . . . . . . . . . . p. 16

5 Datapath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17

6 Comportamento generico para todas as instrucoes . . . . . . . . . . . . p. 19

7 Comportamento comum a todas as instrucoes do formato byte . . . . . p. 20

8 Comportamento especıfico da instrucao DECFSZ . . . . . . . . . . . . p. 20

9 Pipeline simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

10 Comportamento de um desvio incondicional . . . . . . . . . . . . . . . p. 21

11 Comportamento de um desvio condicional . . . . . . . . . . . . . . . . p. 21

12 Forwarding do acumulador . . . . . . . . . . . . . . . . . . . . . . . . . p. 22

13 Forwarding do banco de registradores . . . . . . . . . . . . . . . . . . . p. 22

14 Numero de instrucoes executadas . . . . . . . . . . . . . . . . . . . . . p. 26

15 Tamanho de codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

16 Tempo de simulacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

17 Instrucoes executadas x buscadas . . . . . . . . . . . . . . . . . . . . . p. 28

Lista de Tabelas

1 Conjunto de instrucoes do PIC . . . . . . . . . . . . . . . . . . . . . . p. 13

2 Descricao dos benchmarks utilizados . . . . . . . . . . . . . . . . . . . . p. 23

3 Dados sobre os benchmarks . . . . . . . . . . . . . . . . . . . . . . . . p. 24

4 Impacto de hazards de controle no pipeline . . . . . . . . . . . . . . . . p. 28

Resumo

Com a abundancia de dispositivos disponıveis em um unico chip e a demanda impostapor aplicacoes cada vez mais desafiantes dentro da industria de sistemas embarcados, vemaparecendo no mercado, sistemas integrados de software e hardware (CPU, memoria eperifericos), os chamados Systems-on-Chip(SoCs).

Para reduzir o custo de desenvolvimento e acomodar o time-to-market, o projeto deSoCs tende a adotar uma plataforma-alvo, ou seja, uma arquitetura de referencia con-cebida para viabilizar o reuso de seus componentes, chamados de blocos de propriedadeintelectual (IPs). Tal plataforma pode entao ser personalizada para uma aplicacao es-pecıfica, atraves da remocao de IPs desnecessarios e/ou inclusao de novos IPs.

Este trabalho aborda a modelagem eficiente de um IP. O IP modelado e o PIC 16F84,um micro-controlador de uso bastante difundido na industria. Sao apresentados doismodelos: um puramente funcional e outro com precisao de ciclos. Tais modelos estaodisponıveis em repositorio publico.

Palavras Chave: SoCs, IP, SystemC, ArchC.

7

1 Introducao

Os microprocessadores fazem parte de nossas vidas ja ha algum tempo. No entanto,

eles se tornaram poderosos o suficiente para realizar funcoes verdadeiramente sofisticadas,

somente nos ultimos anos.

A evolucao da tecnologia dos circuitos integrados, propulsora desta explosao no poder

dos microprocessadores, regida pela lei de Moore1 resulta em milhoes de portas logicas em

uma unica pastilha de silıcio. Essa enorme oferta de hardware, combinada com a crescente

demanda de aplicacoes na industria de sistemas embarcados, resultou no aparecimento de

sistemas integrados de hardware (CPU, memoria e perifericos) e software sob a forma de

Systems-on-Chip (SoCs)[1].

Devido ao crescimento do numero de transistores em progressao geometrica, os proje-

tos de sistemas embarcados se tornam viaveis apenas se utilizadas ferramentas de Projeto

Auxiliado por Computador (CAD) e Automacao de Projeto Eletronico (EDA).

Para reduzir o custo de desenvolvimento e acomodar o time-to-market, o projeto de

SoCs tende a adotar uma plataforma-alvo [18], ou seja, uma arquitetura de referencia

concebida para viabilizar o reuso de seus componentes, chamados de blocos de proprie-

dade intelectual (IPs). Tal plataforma pode entao ser personalizada para uma aplicacao

especıfica, atraves da remocao de IPs desnecessarios e/ou inclusao de novos IPs. Em-

bora motivada sobretudo pelas necessidades do projeto de SoCs, a nocao de plataforma

tambem norteia o projeto de sistemas implementados em logica reconfiguravel [5, 7].

O processo de personalizacao de uma plataforma requer a exploracao de arquiteturas

alternativas resultantes da selecao de diferentes conjuntos de IPs. Tal exploracao envolve

a verificacao do comportamento do sistema em face dos requisitos funcionais, a estimativa

de desempenho em face de restricoes de tempo real e a estimativa de potencia em face

da necessidade de baixo consumo de energia. Isso requer a disponibilidade de modelos

1A Lei de Moore preve que, a cada 18 meses, dobra o numero de transistores em um circuito integrado(CI).

8

eficientes para cada um dos IPs.

Este trabalho aborda a modelagem eficiente de um IP, em dois nıveis de abstracao

diferentes: um puramente funcional e outro com precisao de ciclos. O IP modelado

corresponde a um micro-controlador de uso bastante difundido na industria, o PIC 16F84.

Ambos os modelos foram descritos formalmente, sendo validados atraves de um conjunto

de casos de teste.

O trabalho desenvolvido faz parte do projeto DESERT - Desenvolvimento de Software

para Sistemas Embutidos sob Restricoes de Tempo Real do Laboratorio de Automacao e

Projeto de Sistemas (LAPS).

O primeiro modelo descrito neste trabalho (descrito no nıvel puramente funcional)

foi desenvolvido em parceria com Leonardo Taglieti, do Programa de Pos Graduacao em

Ciencias da Computacao (PPGCC) da UFSC [21]. O segundo modelo foi integralmente

desenvolvido pelo autor.

O restante deste trabalho esta organizado como segue: a arquitetura-alvo escolhida

sera brevemente descrita na proxima secao (Secao 2); a linguagem de descricao e as

estrategias utilizadas na modelagem funcional e com precisao de ciclos, na secao 3. O

processo de validacao experimental dos modelos e os resultados obtidos serao relatados

na secao 4 e, finalmente, na secao 5 serao apresentadas as conclusoes e os trabalhos futuros.

9

2 O Micro-controlador PIC

Esta secao descreve sucintamente a arquitetura e a organizacao do micro-controlador

PIC, cuja modelagem sera abordada nas secoes 3 e 3.3. Mais informacoes sobre este

micro-controlador podem ser obtidas na pagina oficial do fabricante [9] e no manual de

referencia [8]. Para detalhes sobre programacao e utilizacao do PIC, as referencias [3] e

[14] podem ser consultadas.

O PIC e um micro-controlador inspirado em arquiteturas RISC que adota maquina de

Harvard baseada em acumulador [13], permitindo que as palavras de dados e de instrucao

possuam tamanhos diferentes, (8 e 14-bits respectivamente).

Com excecao das instrucoes de desvio, que possuem latencia1 1, as demais instrucoes

possuem latencia 0.

O acumulador do PIC e comumente referenciado por W, notacao que sera doravante

adotada neste texto.

2.1 Conjunto de instrucoes do PIC

O PIC possui 35 instrucoes que podem ser separadas em 3 diferentes formatos:

• Orientadas a byte: 18 instrucoes podem ser mapeadas para este formato, elas

possuem no maximo dois operandos e operam sobre dados em registradores.

• Orientadas a bit: Apenas 4 instrucoes sao mapeadas para este formato, que

agrupa instrucoes para verificacao e alteracao de bits em um dado registrador. E

neste formato que se encontram algumas instrucoes de desvio condicional (Bit Test

f, Skip if Clear - BTFSC e Bit Test f, Skip if Set - BTFSS ).

1O autor utiliza o termo latencia, neste contexto, para se referir ao numero de ciclos perdidos entre otermino da busca de uma intrucao e o ınicio da busca da proxima instrucao efetiva, como mostra a figura10.

10

• Literal: Neste formato se encontram as operacoes sobre valores imediatos, que

operam o acumulador com um literal contido na propria instrucao. Exemplos de

instrucoes deste formato sao ADDLW, ANDLW e MOVLW.

• Controle: As instrucoes mapeadas para este formato sao responsaveis, dentre ou-

tras operacoes de controle, pelas operacoes de desvio incondicional (GOTO), cha-

mada e retorno de procedimento (CALL, RETURN, RETLW ) e ainda retorno de

interrupcao (RETFIE ).

O conjunto de instrucoes do PIC esta descrito na tabela 1, extraıda do manual de

referencia [8].

2.2 O Registrador de status

O registrador STATUS e um registrador de uso especial que armazena, em seus 3 bits

menos significativos, informacoes sobre resultados das ultimas operacoes aritmeticas.

A coluna Status Affected presente na tabela 1 representa os bits do registrador STA-

TUS afetados apos a execucao de uma dada instrucao, como segue:

• Z: Zero bit (bit 2)

E 1 se o resultado de uma operacao aritmetica ou logica foi zero. Em caso contrario,

e 0.

• DC: Digit Carry/borrow bit (bit 1)

E 1 se ocorreu um “vai um” do terceiro para o quarto bit nas instrucoes de adicao

e 0 em caso contrario. Nas instrucoes de subtracao, este bit sera 0 se ocorreu um

“vem um”, do terceiro para o quarto bit e 1 em caso contrario.

• C: Carry/borrow bit (bit 0)

E 1 se ocorreu um carry-out no setimo bit durante uma instrucao de adicao e 0 em

caso contrario. Nas instrucoes de subtracao, este bit sera 0 se ocorreu um “vem

um” no bit mais significativo e 1 em caso contrario. Nas instrucoes de rotacao, ele

sera carregado com o bit mais ou menos significativo do registrador operado, para

rotacao a direita e esquerda (RRF e RLF ) respectivamente.

Os bits C e Z em conjunto com as operacoes de subtracao e de verificacao de bits,

sao suficientes para executar qualquer operacao de comparacao (=, ! =, <, <=, >, >=),

11

uma vez que um “vem um” em uma operacao de subtracao so ocorrera quando o primeiro

operando for menor que o segundo. Assim o efeito dessas operacoes, e equivalente por

exemplo, ao das operacoes slt, beq, bne do MIPS [12].

2.3 Enderecamento indireto

O PIC nao possui uma instrucao de desvio indireto, como a instrucao jr do MIPS.

No entanto, possui uma outra caracterıstica denominada enderecamento indireto.

O enderecamento indireto no PIC se baseia em tres registradores de uso especifico,

que sao:

• INDF: O registrador INDF nao e um registrador fısico, uma leitura no registrador

INDF retornara o valor contido no registrador cujo endereco esta armazenado no

registrador FSR.

• FSR: O registrador FSR e um ponteiro que recebe o endereco do registrador que

sofrera as leituras e escritas executadas no registrador INDF.

• PCL: O registrador PCL mantem os 8 bits menos significativos do PC. Ao contrario

do PCLATH que mantem os 5 bits mais significativos do PC (que e composto de

13 bits), PCL e um registrador de leitura e escrita.

A figura 1 apresenta um exemplo de enderecamento indireto de instrucoes, onde a

primeira instrucao (linha 1) efetua uma adicao de um valor pre-carregado em W, com

o valor presente em FSR, armazenando o resultado no proprio FSR. Move o valor do

registrador indicado por FSR para o acumulador na segunda instrucao (linha 2) represen-

tando o carregamento de um valor de uma tabela de enderecos (onde FSR e o endereco

da tabela e W o ındice) e a ultima instrucao (linha 3) representa a escrita deste valor no

PC, fazendo o fluxo do programa desviar para o endereco indicado, um case de um bloco

switch por exemplo (tendo o mesmo efeito da instrucao jr do MIPS).

Figura 1: Enderecamento indireto de instrucoes

12

A figura 2 apresenta um exemplo de enderecamento indireto de dados, onde as duas

primeiras instrucoes sao identicas ao exemplo anterior, porem representam uma operacao

de aritmetica de ponteiros (FSR e a base do ponteiro) e finalmente armazena o valor

contido em W para um registrado de uso geral (linha 3), para ser usado no futuro.

Figura 2: Enderecamento indireto de dados

Estes registradores sao utilizados para a execucao dos ponteiros das linguagens de

alto nıvel, bem como blocos switch e o polimorfismo das linguagens orientadas a objeto.

Isto porque e permitido escrever no byte menos significativo do contador de programa

(PCL), e assim o enderecamento indireto pode ser usado tanto para dados quanto para

instrucoes.

13

Mnemonic Description Cycles 14-Bit Opcode StatusOperands MSb LSb Affected

BYTE-ORIENTED FILE REGISTER OPERATIONSADDWF f,d Add W and f 1 00 0111 dfff ffff C,DC,ZANDWF f,d AND W with f 1 00 0101 dfff ffff ZCLRF f Clear f 1 00 0001 1fff ffff ZCLRW - Clear W 1 00 0001 0xxx xxxx ZCOMF f,d Complement f 1 00 1001 dfff ffff ZDECF f,d Decrement f 1 00 0011 dfff ffff ZDECFSZ f,d Decrement f, Skip if 0 1(2) 00 1011 dfff ffffINCF f,d Increment f 1 00 1010 dfff ffff ZINCFSZ f,d Increment f, Skip if 0 1(2) 00 1111 dfff ffffIORWF f,d Inclusive OR W with f 1 00 0100 dfff ffff ZMOVF f,d Move f 1 00 1000 dfff ffff ZMOVWF f Move W to f 1 00 0000 1fff ffffNOP - No Operation 1 00 0000 0xx0 0000RLF f,d Rotate Left f through Carry 1 00 1101 dfff ffff CRRF f,d Rotate Right f through Carry 1 00 1100 dfff ffff CSUBWF f,d Subtract W from f 1 00 0010 dfff ffff C,DC,ZSWAPF f,d Swap nibbles in f 1 00 1110 dfff ffffXORWF f,d Exclusive OR W with f 1 00 0110 dfff ffff Z

BIT-ORIENTED FILE REGISTER OPERATIONSBCF f,b Bit Clear f 1 01 00bb bfff ffffBSF f,b Bit Set f 1 01 01bb bfff ffffBTFSC f,b Bit Test f, Skip if Clear 1(2) 01 10bb bfff ffffBTFSS f,b Bit Test f, Skip if Set 1(2) 01 11bb bfff ffff

LITERAL AND CONTROL OPERATIONSADDWF f,d Add W and f 1 00 0111 dfff ffff C,DC,ZANDWF f,d AND W with f 1 00 0101 dfff ffff ZCLRF f Clear f 1 00 0001 1fff ffff ZCLRW - Clear W 1 00 0001 0xxx xxxx ZCOMF f,d Complement f 1 00 1001 dfff ffff ZDECF f,d Decrement f 1 00 0011 dfff ffff ZDECFSZ f,d Decrement f, Skip if 0 1(2) 00 1011 dfff ffffINCF f,d Increment f 1 00 1010 dfff ffff ZINCFSZ f,d Increment f, Skip if 0 1(2) 00 1111 dfff ffffIORWF f,d Inclusive OR W with f 1 00 0100 dfff ffff ZMOVF f,d Move f 1 00 1000 dfff ffff ZMOVWF f Move W to f 1 00 0000 1fff ffffNOP - No Operation 1 00 0000 0xx0 0000RLF f,d Rotate Left f through Carry 1 00 1101 dfff ffff CRRF f,d Rotate Right f through Carry 1 00 1100 dfff ffff CSUBWF f,d Subtract W from f 1 00 0010 dfff ffff C,DC,ZSWAPF f,d Swap nibbles in f 1 00 1110 dfff ffffXORWF f,d Exclusive OR W with f 1 00 0110 dfff ffff Z

Tabela 1: Conjunto de instrucoes do PIC

14

3 Modelagem Funcional

A modelagem funcional de um sistema nao considera como este sistema sera imple-

mentado. Somente o comportamento da correlacao entre entradas e saıdas e relevante

neste nıvel de abstracao.

Para descrever o micro-controlador PIC, foi utilizada uma linguagem de descricao de

arquitetura (ADL), que sera brevemente introduzida na secao seguinte.

3.1 A linguagem de descricao de arquiteturas ado-

tada

ArchC e uma linguagem de descricao de arquitetura que foi desenvolvida no Labo-

ratorio de Sistemas Computacionais (LSC) do Instituto de Computacao da Universidade

de Campinas (IC/UNICAMP) [23].

ArchC e baseada em SystemC [19, 11] e esta foi a principal razao de sua escolha no

ambito deste projeto.

Uma descricao ArchC e composta de duas partes principais. A primeira e a descricao

do conjunto de instrucoes da arquitetura (AC ISA), onde o projetista disponibiliza todos

os detalhes sobre o conjunto de instrucoes, tais como: nome das instrucoes, formatos,

tamanhos e outras informacoes necessarias para decodifica-las. A segunda parte e a

descricao dos elementos da arquitetura (AC ARCH), onde o projetista descreve a lista

de recursos da arquitetura, tais como modulos de armazenamento, estrutura do pipeline,

etc.

A partir destas duas descricoes, o pre processador ArchC (acpp) gera o esqueleto

do simulador da arquitetura, que contem as assinaturas dos metodos que especificam o

comportamento de cada instrucao, o comportamento comum a cada formato de instrucao

e o comportamento comum a todas as instrucoes [23, 17].

15

ArchC e uma linguagem adequada tanto para a modelagem puramente funcional

quanto para a modelagem funcional com precisao de ciclos.

3.2 Modelagem puramente funcional

O modelo puramente funcional do PIC 16F84 e composto de 3 arquivos basicos. O

primeiro contem a descricao da arquitetura (pic16F84.ac). Parte desta descricao pode ser

visualizada na figura 3, onde estao declarados respectivamente, 5 MB de memoria, um

banco com 256 registradores, a palavra de dados de 8 bits e um registrador chamado W (o

acumulador). No construtor (ARCH CTOR), sao declarados o arquivo com a descricao

da arquitetura do conjunto de instrucoes (pic16F84 isa.ac) e o endian.

Figura 3: Descricao da arquitetura do PIC 16F84

A descricao do arquitetura do conjunto de instrucoes (ISA) e composta de tres par-

tes, como mostra a figura 4, que contem apenas um trecho do modelo completo. A

primeira parte e a declaracao dos formatos de instrucoes. Sao declarados quatro forma-

tos de instrucao, todos com 16 bits1 ao todo. A segunda secao associa as instrucoes aos

seus respectivos formatos. Por exemplo, as instrucoes BCF, BSC, BTFSC e BTFSS sao

associadas ao formato bit (declarado como Format_Bit). Na ultima parte, encapsulada

no construtor ISA (ISA_CTOR), cada instrucao e associada a um mnemonico e os campos

fixos sao definidos atraves da diretiva set_decoder. Por exemplo, a instrucao MOVWF

e associada ao minemonico MOVWF %f, e os campos opbyte e d sao configurados para seus

valores fixos, opbyte com o opcode da instrucao e o campo d, que indica se o registrador

destino e o acumulador ou o proprio registrador indicado na instrucao. Como MOVWF

sempre movera o valor do acumulador para um registrador destino, o campo d e fixo em

1.

1Foram acrescentados 2 dummy bits a todos os formatos de instrucao devido a uma limitacao dalinguagem ArchC, que aceita apenas comprimentos de instrucao em multiplos de 8.

16

Figura 4: Descricao da arquitetura do conjunto de instrucoes

3.3 Modelagem funcional com precisao de ciclos

Alem do comportamento da correlacao entre entradas e saıdas, a modelagem funcional

com precisao de ciclos, captura os atrasos decorrentes da execucao de cada operacao

(timing).

Para construir tal modelo do micro-controlador PIC, foi necessario deduzir a estrutura

de seu pipeline, ja que o manual do fabricante [8] e bastante e superficial nesse aspecto.

Foi necessario usar elementos da linguagem ArchC nao utilizados na descricao do

modelo funcional, como segue:

ac pipe - Constroi um pipeline com tantos estagios quantos forem nominados. Por

exemplo, no modelo desenvolvido, a declaracao: ac_pipe pipe = {IF, ID, EX, WB};,

resulta em um pipeline com 4 estagios, que serao associados com as etapas de busca

(IF), decodificacao (ID), execucao (EX) e escrita no destino (WB).

ac format - Cria um formato que pode ser associado a um registrador. Possue sintaxe

17

semelhante a da diretiva de mesmo nome utilizada na descricao do conjunto de

instrucoes, para definir um formato de instrucao. Essa diretiva foi utilizada para

distinguir os varios campos dos registradores do pipeline.

3.3.1 Datapath

Na figura 5 podemos observar uma versao simplificada do datapah (onde os sinais de

controle e elementos menos importantes foram omitidos), onde os registradores de pipeline

(IF ID, ID EX e EX WB) delimitam a fronteira de cada estagio.

Como podemos observar, no primeiro estagio (IF) acontece a busca da instrucao;

no segundo estagio (ID), ocorrem paralelamente a decodificacao da instrucao e a leitura

do banco de registradores e do acumulador (ambas especulativas). Ainda nesse estagio,

apos a decodificacao, ocorre a selecao do operando A da Unidade Logica e Aritmetica

(ULA), bem como a escrita no contador de programa (PC) para as instrucoes de desvio

incondicional, no estagio seguinte (EX) ocorre a selecao do operando B bem como a

operacao na ULA, e no ultimo estagio (WB) ocorre a escrita no banco de registradores e

no acumulador.

Figura 5: Datapath

18

3.3.2 Estrutura do modelo

Para construir um modelo de precisao de ciclos, e necessario conhecer a maneira como

ArchC gerencia a execucao dos estagios do pipeline. Todas as instrucoes passam por todos

os estagios indicados, a menos que sejam eliminadas do pipeline, sendo que a cada ciclo,

um estagio de cada instrucao e executado, partindo do ultimo ate chegar ao primeiro

estagio.

Para cada instrucao, independentemente do estagio, ocorre o seguinte processo:

1. O comportamento generico (comum a todas as instrucoes) e executado.

2. O comportamento do formato da instrucao e executado.

3. O comportamento especifico da instrucao e executado.

As figuras 6, 7 e 8 sao exemplos de cada um dos comportamentos descritos acima,

conforme explicado a seguir.

A figura 6 define o comportamento comum a todas as instrucoes. Como pode ser

observado, a variavel stage armazena o estagio corrente, permite fazer tratamentos di-

ferenciados para cada estagio do pipeline (essa mesma variavel e utilizada nos demais

comportamentos). No estagio IF ocorre o incremento do PC, sendo que a busca da ins-

trucao (que ocorre no mesmo estagio) fica a cargo do simulador ArchC. No estagio ID,

ocorre a leitura do acumulador (que e o segundo operando da ULA por padrao), e todos

os sinais de escrita sao desabilitados. No estagio EX, ocorre apenas a copia dos valores

comuns aos registradores do pipeline ID EX e EX WB. E no estagio EX ocorre a escrita

no registrador alvo e nos bits especıficos do registrador de STATUS (somente quando a

escrita estiver habilitada). Nao ocorrem acessos de leitura e escrita na memoria, devido a

sua inexistencia no PIC 16F84 que utiliza o espaco de enderecamento apenas para mapear

os seus 68 registradores de uso geral.

Na figura 7, o comportamento das instrucoes do formato byte, que tem o registrador

destino indicado no campo d e o registrador especificado no campo f sao armazenados

para uso posterior, bem como o primeiro operando da ULA que e configurado com o valor

do mesmo registrador.

Na figura 8, o comportamento especıfico da instrucao DECFSZ que habilita a escrita

no estagio ID. No estagio EX, decrementa-se o valor do registrador de um e verifica-se se

19

Figura 6: Comportamento generico para todas as instrucoes

o resultado e igual a zero. Se o resultado for nulo, elimina-se do pipeline a instrucao que

atualmente ocupa o estagio ID.

3.3.3 Hazards de controle

Na ausencia de hazards, o pipeline opera de modo que uma nova instrucao seja iniciada

a cada ciclo, como ilustra a figura 9:

Uma instrucao e buscada, decodificada, executada e seu resultado e escrito no regis-

trador destino. E desta forma, enquanto a instrucao estiver ocupando um determinado

estagio, a instrucao seguinte estara ocupando o estagio anterior.

No entanto, as instrucoes de desvio resultam em hazards de controle. Isto porque uma

instrucao de desvio so e decodificada no estagio ID, e nesse caso a instrucao seguinte a

instrucao de desvio, que nao necessariamente sera a proxima instrucao a ser executada,

ja foi buscada. Os proximos paragrafos descrevem como essa instrucao e nulificada.

20

Figura 7: Comportamento comum a todas as instrucoes do formato byte

Figura 8: Comportamento especıfico da instrucao DECFSZ

Para as instrucoes de desvio incondicional (CALL, GOTO, RETLW, RETFIE, RE-

TURN), logo que a instrucao e identificada no estagio ID, a instrucao que atualmente

ocupa o estagio IF e descartada, como ilustra a figura 10.

Para as instrucoes de desvio condicional, quando a condicao de desvio nao e satisfeita,

instrucao se comporta como as demais instrucoes. No entanto, quando a condicao for

verificada no estagio EX, a instrucao seguinte deve ser eliminada do pipeline (enquanto

esta no estagio ID), como o exemplo da figura 11.

E importante ressaltar que o PIC nao possui instrucoes de desvio condicional para

um endereco absoluto ou mesmo relativo. Quando a condicao de desvio e satisfeita, o

endereco alvo e sempre a segunda instrucao que sucede a instrucao de desvio, sendo a

instrucao sucessora imediatamente anulada.

Mesmo que a instrucao corrente seja um desvio, a proxima instrucao e buscada no

21

Figura 9: Pipeline simples

Figura 10: Comportamento de um desvio incondicional

ciclo seguinte independentemente do resultado do teste.

Figura 11: Comportamento de um desvio condicional

3.3.4 Hazards de dados

Como a leitura e a escrita do acumulador/banco de registradores, estao separadas por

1 estagio (a leitura ocorre no estagio ID, enquanto a escrita no estagio WB), foi necessario

tratar os hazards que ocorrem quando uma instrucao acessar o valor de um registrador

que a instrucao no estagio EX ira atualizar somente no proximo ciclo (estagio WB).

Essa situacao e contornada utilizando a tecnica de forwarding ou bypassing [12], que

22

neste caso consiste em adiantar o resultado da ULA do ciclo atual, para um de seus

operandos no proximo ciclo, antes mesmo que este valor seja escrito no registrador destino.

O forwarding do valor a ser escrito no acumulador foi tratado no comportamento co-

mum a todas as instrucoes, como pode ser visto na figura 12. Quando para uma instrucao

no estagio WB a escrita estiver habilitada e o registrador destino for o acumulador, o

valor do operando op B e obtido diretamente da saıda da ULA. Em caso contrario, o

valor default de op B e lido do acumulador.

Figura 12: Forwarding do acumulador

O forwarding de um valor a ser escrito no banco de registradores foi implementado

de maneira similar, como pode ser visto na figura 13. Ele e tratado no comportamento

dos formatos byte e bit (Format_Byte e Format_Bit). Quando, para instrucao no estagio

WB, a escrita estiver habilitada, e o registrador for o mesmo da instrucao no estagio EX,

o valor sera obtido diretamente da saıda da ULA. Em caso contrario o valor default de

op A e lido do banco de registradores.

Figura 13: Forwarding do banco de registradores

23

4 Resultados Experimentais

Para validacao dos modelos do PIC foram utilizados 8 dos 9 benchmarks disponıveis

na pagina oficial do projeto Dalton [2]. Estes sao os mesmos benchmarks utilizados para

validar o modelo do 8051 construıdo na Universidade Federal de Pernambuco - UFPE,

e tambem disponıvel em [23]. O unico benchmark nao utilizado foi o xram por nao ser

aplicavel ao PIC cuja memoria e bastante limitada.

Os benchmarks foram compilados com o compilador C da CCS r©, e montados com

um montador gerado automaticamente atraves de uma ferramenta construıda em nosso

grupo de pesquisa [20]. Esses programas exploraram muitas das situacoes reais de um

programa embutido e serao melhor descritos na proxima secao.

4.1 Benchmarks e configuracao experimental

A tabela 2 apresenta uma breve descricao de cada um dos 8 benchmarks utilizados.

cast Obtem cada byte que compoe uma constante do tipo long (4 bytes),utilizando coersao para byte (unsigned char) e deslocamentos.

divmul Emula operacoes de multiplicacao, divisao e modulo sobre bytes.fib Obtem os dez primeiros numeros da serie de Fibonaci [4].gcd Obtem o maior divisor comum entre 47 e 11 utilizando-se do

algoritmo de Euclides [10].int2bin Obtem os bits que compoe um numero inteiro, utilizando

principalmente deslocamentos e operadores bit-a-bit.negcnt Utiliza coersao de inteiros sinalizados para bytes sinalizados

(unsigned char).sort Ordena um array com 10 elementos utilizando-se do algoritmo

Buble Sort [15]. O programa utiliza principalmente comparacoes.sqroot Extrai a raiz quadrada de 25, utilizando emulacao de ponto

flutuante e operacoes sobre os numeros de ponto flutuante emulados.

Tabela 2: Descricao dos benchmarks utilizados

24

A tabela 3 mostra, para cada programa, o tamanho do codigo (expresso em palavras

de instrucao de 14-bits), e o numero de instrucoes executadas.

Tamanho de Numero de instrucoesC codigo (em palavras) executadas

cast.c 60 68divmul.c 106 296

fib.c 70 358gcd.c 32 125

int2bin. 36 256negcnt.c 30 150sort.c 110 2227

sqroot.c 863 6328

Tabela 3: Dados sobre os benchmarks

O ambiente utilizado para realizar os experimentos foi um AMD Athlon(TM) XP

2.4+ GHz, rodando Debian GNU/Linux (versao do Kernel 2.6.8-2-k7), com 512 MB de

memoria principal e 256 KB de cache.

4.2 Validacao dos modelos

O processo de validacao dos modelos consistiu de tres etapas distintas, os testes

unitarios, os de integracao e os de regressao [16].

4.2.1 Testes unitarios

Os testes unitarios consistem em testar cada unidade do sistema separadamente, neste

caso, cada instrucao. Nesta etapa de validacao dos modelos, efetuamos pelo menos um

teste para cada instrucao, onde um pequeno programa assembly que utiliza a instrucao

foi construıdo e executado. As saıdas foram analisadas e comparadas com os resultados

esperados.

Ao final do processo, todas as instrucoes de ambos os modelos passaram nos testes

unitarios.

4.2.2 Testes de integracao

Os testes de integracao objetivam testar o funcionamento das unidades do sistema em

conjunto, procurando descobrir defeitos na interface entre os modulos.

25

Utilizando o conjunto de benchmarks apresentados anteriormente, cujas saıdas espe-

radas sao conhecidas (estao disponıveis na pagina do projeto Dalton [2]). as seguintes

etapas foram realizadas:

1. Para cada benchmark, analisou-se o codigo gerado pelo compilador, descobrindo a

qual registrador o valor de saıda e associado, verificou-se tambem se esse mesmo

registrador nao e utilizado em outras partes do codigo.

2. Gerou-se o simulador, e carregou-se cada um dos benchmarks. Analisou-se as saıdas

e verificou-se se corresponderam exatamente as saıdas esperadas.

Ambos os modelos tiveram saıdas equivalentes as esperadas para todos os benchmarks.

Deve-se resalvar que apenas as instrucoes ANDLW, CLRW, CLRWDT, INCFSZ, IORWF,

RETFIE, RETURN e SWAPF nao foram cobertas nos testes de integracao, pois nao estao

presentes em nenhum dos 8 benchmarks utilizados durante os testes de integracao.

4.2.3 Testes de regressao

Em qualquer sistema computacional, a adicao de novas funcionalidades e bastante

comum. Um teste de regressao e a re-execucao de um subconjunto de testes, ja aplicados

em momento anterior, para verificar que apos um novo modulo ser adicionado, ou uma

correcao ser efetuada, o sistema continua em correto funcionamento.

Para que o teste de regressao pudesse ser automaticamente aplicado, todos os testes

de integracao, apos validados, tiverem suas saıdas salvas. Posteriormente, sempre que

necessario, quando o teste for invocado os testes de integracao serao re-executados, e suas

saıdas comparadas com as anteriormente salvas (ja validadas), ignorando informacoes

mutaveis (tempo de simulacao por exemplo). Em caso de falha, o teste informa quais

benchmarks falharam.

O teste de regressao foi disponibilizado ao grupo de suporto do Projeto ArchC, e sera

aplicado a ambos os modelos, sempre que uma nova versao das ferramentas for gerada.

4.3 Comparacao com modelo congenere

Com o objetivo de avaliar a eficiencia dos modelos uma bateria de experimentos foi

realizada.

26

Primeiro, foram feitas comparacoes com um modelo congenere, o do micro-controlador

8051, desenvolvido na UFPE.

A figura 14 apresenta uma comparacao entre o numero de instrucoes executadas para

um subconjunto dos benchmarks. Os benchmarks para o 8051 foram compilados com o

Keil’s i8051 compiler.

Note que, devido a inexistencia de um compilador de domınio publico que gere codigo

para ambos os modelos, dois compiladores comerciais foram utilizados. Portanto, diferen-

tes tecnicas de otimizacao podem ter sido utilizadas, dificultando a comparacao feita dos

resultados.

Figura 14: Numero de instrucoes executadas

Percebe-se que, o numero de instrucoes executadas para o PIC e sempre inferior. Este

comportamento e provavelmente devido a dificuldade de otimizar codigo para o 8051 ou

deficiencia do compilador utilizado.

Como o 8051 e uma arquitetura CISC, a superioridade do PIC ja era esperada, pois

os compiladores em geral, tem mais facilidade em gerar codigo para arquiteturas RISC

like [12].

A figura 15 apresenta-se uma comparacao em termos de tamanho de codigo (expresso

em bytes).

Para 4 benchmarks o codigo gerado para o PIC e ligeiramente maior do que o do

8051. Este comportamento e esperado uma vez que o PIC usa tamanho fixo para suas

instrucoes. Em dois benchmarks (fib e sort) o codigo gerado para o PIC e 2 a 2,5 vezes

mais compacto.

27

Figura 15: Tamanho de codigo

4.4 Resultados para o modelo puramente funcional

A figura 16 mostra os tempos de simulacao (em unidades de tempo do SystemC) para

os modelos funcionais do PIC e do 8051.

Figura 16: Tempo de simulacao

A diferenca e bastante significativa, chegando a varias vezes em alguns casos (cast

e int2bin por exemplo). Pode-se atribuir essa diferenca principalmente ao processo de

decodificacao das instrucoes, que e bastante complexo para o 8051, devido a variacao no

tamanho das instrucoes e a multiplicidade de formatos, enquanto o PIC possui tamanho

fixo de instrucao e apenas 4 formatos.

28

4.5 Resultados para o modelo com precisao de ciclos

Com a disponibilidade de um modelo funcional com precisao de ciclos, um outro

tipo de analise pode ser realizado. O impacto do numero de instrucoes eliminadas do

pipeline, devido a hazards de controle (ver secao 3.3.3), ou seja, aquelas instrucoes que

sao buscadas, mas, nao chegam a concluir sua execucao (bolhas no pipeline).

Na figura 17 e na tabela 4, podemos observar esses dados.

Figura 17: Instrucoes executadas x buscadas

Benchmarks Numero de Instrucoes Ciclos PerdidosExecutadas Carregadas (%)

cast.c 68 77 11,69%divmul.c 296 363 18,46%

fib.c 358 401 10,72%gcd.c 125 159 21,38%

int2bin. 256 322 20,50%negcnt.c 150 215 30,23%sort.c 2227 2494 10,71%

sqroot.c 6328 7625 17,01%

Tabela 4: Impacto de hazards de controle no pipeline

Em media, para os benchmarks utilizados, 17,59 % das instrucoes carregadas nao

completam sua execucao. No melhor caso 10,71 % nao se completam e no pior, 30,23 %.

O numero de ciclos perdidos poderia ser reduzido com uma tecnica de previsao de

desvios [13], nao suportada no PIC.

29

5 Conclusoes e Trabalhos Futuros

Os modelos descritos mostraram-se bastante robustos em face ao numero de expe-

rimentos realizados e ao numero de benchmarks submetidos, alguns bastante complexos

como, sqroot, por exemplo.

Atraves das comparacoes com o modelo do 8051, pode-se perceber tambem a eficiencia

do modelo do PIC, que se mostrou superior aquele, em termos de tempo de simulacao.

Nao e de conhecimento do autor que modelos similares aos aqui apresentados, estejam

disponıveis em repositorio de domınio publico, o que torna os produtos deste trabalho uma

contribuicao tecnica efetiva para o projeto baseado no reuso de IPs.

Os modelos ja foram certificados pela equipe ArchC e estao disponıveis em seu repo-

sitorio publico [23]. Isto permite que os modelos sejam utilizados na exploracao do espaco

de projeto que demande um microcontrolador, analisando a adequacao em relacao aos

requisitos do sistema ou estimando desempenho.

Os modelos podem ainda ser utilizados na geracao automatica de ferramentas, como

simuladores e montadores que ja estao disponıveis, alem de outras sob desenvolvimento.

A disponibilidade de um modelo com precisao de ciclos permite, por exemplo, a

validacao de ferramentas que envolvam timing, tais como um escalonador de codigo e um

depurador de codigo com precisao de ciclos, alem de fornecer insumos para a ferramenta

de estimativa de consumo de potencia.

5.1 Produtos de trabalho

Os resultados obtidos com este trabalho foram:

• Modelos puramente funcional do PIC 16F84 certificado e disponıvel em re-

positorio publico[23].

30

• Modelo funcional com precisao de ciclos do PIC 16F84 tambem certificado

e disponıvel em repositorio publico[23].

• Artigo em co-autoria, publicado nos anais do XI Workshop IBERCHIP [22].

• Artigo submetido ao Student Forum on Microelectronics 2005 [6].

31

Referencias

[1] Reinaldo Bergamaschi. A to Z of SoCs. In Tutorial apresentado na Escola de Micro-eletronica da SBC Sul (EMICRO 2002), Florianopolis - Brazil, 2002.

[2] Dalton. Synthesizable VHDL model of 8051, 2001. http://www.cs.ucr.edu/ dal-ton/i8051/i8051syn/.

[3] David Jose de Souza. Desbravando o PIC. Erica, Sao Paulo, 2000.

[4] R. A. Dunlap. The Golden Ration and Fibonacci Numbers. World Scientific, 1997.

[5] J. Kempa, S. Y. Lim, C. Robinson, and J. A. Seely. SOPC Builder: Performance byDesign. Winning the SoC revolution: experiences in real design, chapter 8. KluwerAcademic Publishers, 2003.

[6] Gabriel Renaldo Laureano, Leonardo Taglietti, and Luiz Claudio Villar dos San-tos. Functional and cycle-accurate models for the PIC 16F84 micro-controller. Flo-rianopolis, Brazil, September 4-7 2005. Submeted to: Students Forum.

[7] P. Lysaght. Platform FPGAs. Winning the SoC revolution: experiences in real design,chapter 7. Kluwer Academic Publishers, 2003.

[8] Microchip, 1998. PIC 16F8X: 18-pin Flash/EEPROM 8 Bit Microcontrollers.

[9] Microchip, 2005. http://www.microchip.com.

[10] Vıtor Neves. Introducao a Teoria dos Numeros. Departamento de Matematica -Universidade de Aveiro, 2001.

[11] OSCI. SystemC Version 2.0 User’s Guide, 2003.

[12] David A. Patterson and John L. Hennessy. Organizacao e Projeto de Computadores.Campus, 2nd edition, 2000.

[13] David A. Patterson and John L. Hennessy. Arquitetura de Computadores: UmaAbordagem Quantitativa. Campus, 3rd edition, 2003.

[14] Fabio Pereira. Microcontroladores PIC: Programacao em C. Erica, 2003.

[15] Bruno R. Preiss. Data Structures and Algorithms with Object-Oriented Design Patterns in Java. John Wiley and Sons, Inc., 1999.http://www.brpreiss.com/books/opus5/.

[16] Roger S. Pressman. Software Enginnering: A Practitioner’s Approach. Fifth edition,2001.

32

[17] Sandro Rigo. ArchC: Uma linguagem de descricao de Arquiteturas. Instituto deComputacao. Universidade Estadual de Campinas - Brasil, Julho 2004.

[18] A. Sangiovanni-Vincentelli and G. Martin. Platform-based design and software designmethodology for embedded systems. IEEE Design & Test of Computers, 18(6):23–33,November-December 2001.

[19] SystemC Homepage, 2003. http://www.systemc.org.

[20] Leonardo Taglietti, Jose Otavio Carlomagno Filho, Daniel Casarotto, Olinto Jose Va-rella Furtado, and Luiz Claudio Villar dos Santos. Automatic ADL-based assemblergeneration for ASIP programming support. In The 3rd International IEEE Northe-ast Workshop on Circuits and Systems, Quebec City, Canada, June 19-22 2005.http://www.newcas.org.

[21] Leonardo Taglietti, Olinto Jose Varela Furtado, and Luiz Claudio Villar dos Santos.Geracao automatica de ferramentas de suporte ao desenvolvimento de software em-barcado para ASIPs. Master’s thesis, Programa de Pos-graduacao em Ciencias daComputacao - UFSC - Brasil, Florianopolis-SC, Fevereiro 2005.

[22] Leonardo Taglietti, Gabriel Renaldo Laureano, Carlos Rodrigo Toffoli Fernandes, andLuiz Claudio Villar dos Santos. Modelagem do microcontrolador PIC 16F84 para pro-jeto baseado no reuso de IPs. In Anais do XI Workshop IBERCHIP, pages 251–252,Salvador - Bahıa, Brasil, 28-30 de Marco 2005. http://www.iberchip.org/iws2005.

[23] The ArchC Architecture Description Language, 2003. http://www.archc.org.

33

APENDICE A -- Codigo Fonte dos

Modelos

34

A.1 constants.h

1 /*******************************************************

2 * The ArchC PIC 16F84 functional model. *

3 * *

4 * Author: *

5 * Gabriel Renaldo Laureano - [email protected] *

6 * Leonardo Taglietti - [email protected] *

7 * *

8 * For more information on ArchC, please visit: *

9 * http://www.archc.org *

10 *******************************************************/

11 #ifndef CONSTANTS_H

12 #define CONSTANTS_H

13 //Special Function Registers in Bank0

14 #define INDF 00

15 #define TMR0 01

16 #define PCL 02

17 #define STATUS 03

18 #define FSR 04

19 #define PORTA 05

20 #define PORTB 06

21 //Address 07 is a unimplemented data memory location

22 #define EEDATA 08

23 #define EEADR 09

24 #define PCLATH 10 //0A

25 #define INTCON 11 //0B

26 #define OPTION 0x81;

27 #define TRISA 0x85;

28 #define TRISB 0x86;

29 #define EECON1 0x88;

30 #define EECON2 0x89;

31 //Bits in OPTION_REG Register

35

32 #define RBPU 7

33 #define INTEDG 6

34 #define TOCS 5

35 #define T0SE 4

36 #define PSA 3

37 #define PS2 2

38 #define PS1 1

39 #define PS0 0

40 //Bits in INTCON Register

41 #define GIE 7

42 #define EEIE 6

43 #define T0IE 5

44 #define INTE 4

45 #define RBIE 3

46 #define TOIF 2

47 #define INTF 1

48 #define RBIF 0

49 //Bits in STATUS Register

50 #define IRP 7

51 #define RP1 6

52 #define RP0 5

53 #define TO 4

54 #define PD 3

55 #define Z 2

56 #define DC 1

57 #define C 0

58 //Other constants

59 #define ENABLE 1

60 #define UNABLE 0

61 #define W_TARGET 0

62 #define REG_TARGET 1

63 #define SET 1

36

64 #define CLEAR 0

65 #endif /* CONSTANTS_H */

37

A.2 pic16F84.ac

1 /********************************************************


3 * *

4 * Author: *



7 * *



10 *******************************************************/

11

12 AC_ARCH(pic16F84){

13 ac_mem MEM:5M;

14 ac_regbank BANK:256;

15 ac_wordsize 8;

16 ac_reg W;

17

18 ARCH_CTOR(pic16F84) {

19 ac_isa("pic16F84_isa.ac");

20 set_endian("big");

21 };

22 };

38

A.3 pic16F84 isa.ac

1 /*******************************************************


3 * *

4 * Author: *



7 * *



10 *******************************************************/

/*

11 NOTE 1: We consider instruction word as 8 bits size, and for this PC is

12 increased by 2 instead of 1 and insruction addresses are multipled

13 by 2. We needed add 2 dummy bits at begin of instruction to become

14 the instruction word size a two power with 16 bits.

15 NOTE 2: For Literal and Control operations, we replaceed "don’t care’s"

16 for "zeros" in order to keep instruction formats as

17 simple as possible.

*/

18 AC_ISA(pic16F84){

19 //Format Declarations-------------------------------------------------

20 ac_format Format_Byte = "%dummy:2 %opbyte:6 %d:1 %f:7";

21 ac_format Format_Bit = "%dummy:2 %opbit:4 %b:3 %f:7";

22 ac_format Format_Literal = "%dummy:2 %oplit:6 %k:8";

23 ac_format Format_Control = "%dummy:2 %opctrl:3 %kaddress:11";

24

//----------------------------------------------------------------------------

25 //Associations of Formats with instructions---------------------------

26 ac_instr<Format_Byte> CLRWDT,

39

CLRW,CLRF,ADDWF,MOVWF,ANDWF,DECF,INCF,MOVF,NOP,IORWF,SUBWF,XORWF,COMF,DECFSZ,

INCFSZ,RLF,RRF,SWAPF,RETURN,RETFIE,SLEEP;

27 ac_instr<Format_Bit> BCF, BSF, BTFSC, BTFSS;

28 ac_instr<Format_Literal> MOVLW,ANDLW,IORLW,XORLW, ADDLW, SUBLW, RETLW;

29 ac_instr<Format_Control> GOTO, CALL;

30

//----------------------------------------------------------------------------

31 //Addresses Modes-----------------------------------------------------

32 //ac_addr_mode_A GOTO(kaddress);

33 //ac_addr_mode_A CALL(kaddress);

34 //Assembly e Decoder of Instructions----------------------------------

35 ISA_CTOR(pic16F84){

36 //Byte-Oriented File Register Operations--------------------------

37 ADDWF.set_asm("ADDWF %f, %d");

38 ADDWF.set_decoder(opbyte=0x07);

39 ANDWF.set_asm("ANDWF %f, %d");

40 ANDWF.set_decoder(opbyte=0x05);

41 CLRF.set_asm("CLRF %f");

42 CLRF.set_decoder(opbyte=0x01, d=1);

43 CLRW.set_asm("CLRW");

44 CLRW.set_decoder(opbyte=0x01, d=0);

45 COMF.set_asm("COMF %f, %d");

46 COMF.set_decoder(opbyte=0x09);

47 DECF.set_asm("DECF %f, %d");

48 DECF.set_decoder(opbyte=0x03);

40

49 DECFSZ.set_asm("DECFSZ %f, %d");

50 DECFSZ.set_decoder(opbyte=0x0B);

51 INCF.set_asm("INCF %f, %d");

52 INCF.set_decoder(opbyte=0x0A);

53 INCFSZ.set_asm("INCFSZ %f, %d");

54 INCFSZ.set_decoder(opbyte=0x0F);

55 IORWF.set_asm("IORWF %f, %d");

56 IORWF.set_decoder(opbyte=0x04);

57 MOVF.set_asm("MOVF %f, %d");

58 MOVF.set_decoder(opbyte=0x08);

59 MOVWF.set_asm("MOVWF %f");

60 MOVWF.set_decoder(opbyte=0x00, d=1);

61 NOP.set_asm("NOP");

62 NOP.set_decoder(opbyte=0x00, d=0, f=0x00);

63 RLF.set_asm("RLF %f, %d");

64 RLF.set_decoder(opbyte=0x0D);

65 RRF.set_asm("RRF %f, %d");

66 RRF.set_decoder(opbyte=0x0C);

67 SUBWF.set_asm("SUBWF %f, %d");

68 SUBWF.set_decoder(opbyte=0x02);

69 SWAPF.set_asm("SWAPF %f, %d");

70 SWAPF.set_decoder(opbyte=0x0E);

71 XORWF.set_asm("XORWF %f, %d");

72 XORWF.set_decoder(opbyte=0x06);

41

73 //----------------------------------------------------------------

74 //Bit-Oriented File Register Operations --------------------------

75 BCF.set_asm("BCF %f, %b");

76 BCF.set_decoder(opbit=0x04);

77 BSF.set_asm("BSF %f, %b");

78 BSF.set_decoder(opbit=0x05);

79 BTFSC.set_asm("BTFSC %f, %b");

80 BTFSC.set_decoder(opbit=0x06);

81 BTFSS.set_asm("BTFSS %f, %b");

82 BTFSS.set_decoder(opbit=0x07);

83 //----------------------------------------------------------------

84 //Literal Operations----------------------------------------------

85 ADDLW.set_asm("ADDLW %k");

86 ADDLW.set_decoder(oplit=0x3E);

87 ANDLW.set_asm("ANDLW %k");

88 ANDLW.set_decoder(oplit=0x39);

89 //colocada no formato Byte

90 CLRWDT.set_asm("CLRWDT");

91 CLRWDT.set_decoder(opbyte=0x00, d=0, f=0x64);

92 IORLW.set_asm("IORLW %k");

93 IORLW.set_decoder(oplit=0x38);

94 MOVLW.set_asm("MOVLW %k");

95 MOVLW.set_decoder(oplit=0x30);

42

96 SUBLW.set_asm("SUBLW %k");

97 SUBLW.set_decoder(oplit=0x3C);

98 XORLW.set_asm("XORLW %k");

99 XORLW.set_decoder(oplit=0x3A);

100 RETLW.set_asm("RETLW %k");

101 RETLW.set_decoder(oplit=0x34);

102 //----------------------------------------------------------------

103 //Control Operations----------------------------------------------

104 CALL.set_asm("CALL %kaddress");

105 CALL.set_decoder(opctrl=0x04);

106 GOTO.set_asm("GOTO %kaddress");

107 GOTO.set_decoder(opctrl=0x05);


109 RETFIE.set_asm("RETFIE");

110 RETFIE.set_decoder(opbyte=0x0, d=0, f=0x09);


112 RETURN.set_asm("RETURN");

113 RETURN.set_decoder(opbyte=0x00, d=0, f=0x08);


115 SLEEP.set_asm("SLEEP");

116 SLEEP.set_decoder(opbyte=0x0, d=0, f=0x63);

117 //----------------------------------------------------------------

118 };

119 };

43

A.4 pic16F84-isa.cpp

1 /*******************************************************


3 * *

4 * Author: *



7 * *



10 *******************************************************/

11 #include "pic16F84-isa.H"

12 #include "ac_isa_init.cpp"

13 #include "constants.h"

14 //Uncomment this line to view the debug model

15 #define DEBUG_MODEL

16 #ifdef DEBUG_MODEL

17 #include <stdio.h>

18 #include <stdarg.h>

19 inline int dprintf (const char *format, ...)

20 {

21 int ret;

22 va_list args;

23 va_start (args, format);

24 ret = vfprintf (stdout, format, args);

25 va_end (args);

26 return ret;

27 }

28 #else

29 inline void dprintf (const char *format, ...)

30 {

44

31 }

32 #endif

33 //Auxiliar Status Register

34 sc_uint < 8 > status;

35 /**

36 * Stack of instruciton addresses.

37 */

38 class

39 {

40 private:

41 char tos;

42 int addresses[8];

43 public:

44 void push (int address)

45 {

46 addresses[tos] = address;

47 dprintf ("Position in Stack=%X\n", tos);

48 tos = (tos + 1) % 8;

49 }

50 int pop ()

51 {

52 tos = (tos + 7) % 8;

53 dprintf ("Position in Stack=%X\n", tos);

54 return addresses[tos];

55 }

56 int top ()

57 {

58 return addresses[(tos + 7) % 8];

59 }

60 }

45

61 STACK;

62 /**

63 * Method for read a register from reg bank.

64 */

65 ac_word read (unsigned address)

66 {

67 if (address == INDF)

68 {

69 address = BANK.read (FSR);

70 }

71 return BANK.read (address);

72 }

73 /**

74 * Method for write a register from reg bank.

75 */

76 void write (unsigned address, ac_word datum)

77 {


79 {

80 address = BANK.read (FSR);

81 }

82 BANK.write (address, datum);

83 }

84 /**

85 * Method for verify if there is or not a carry out.

86 */

87 bool carry_out (char value1, char value2)

88 {

89 if ((value1 < 0) && (value2 < 0))

90 {

46

91 return true;

92 }

93 else

94 {

95 if (!((value1 >= 0) && (value2 >= 0)))

96 {

97 if (value2 >= -value1)

98 return true;

99 }

100 }

101 return false;

102 }

103 /**

104 * Method for verify if there is or not a digit carry out.

105 */

106 bool digit_carry_out (char value1, char value2)

107 {

108 char sum;

109 bool carry_out;

110 value1 &= 0x0F;

111 value2 &= 0x0F;

112 sum = value1 + value2;

113 carry_out = sum >> 4;

114 return carry_out;

115 }

116 /**

117 * Negative method for verify if there is or not a borrow.

118 */

47

119 bool inline not_borrow (char value1, char value2)

120 {

121 return ((unsigned char) value1 >= (unsigned char) value2);

122 }

123 /**

124 * Negative method for verify if there is or not a digit borrow.

125 */

126 bool inline not_digit_borrow (char value1, char value2)

127 {

128 return not_borrow (value1 << 4, value2 << 4);

129 }

130 /**

131 * Method for read all STATUS Register.

132 */

133 void read_status ()

134 {

135 status = read (STATUS);

136 dprintf ("Current Value of STATUS Register: %X \nBITS: \n",

137 read (STATUS));

138 dprintf ("Z DC C\n");

139 dprintf ("%d %d %d", (status[Z] == 1 ? 1 : 0), (status[DC] == 1 ? 1 :

0),

140 (status[C] == 1 ? 1 : 0));

141 dprintf ("\n\n");

142 }

143 /**

144 * Method for write in the status reg.

145 */

146 void write_status ()

147 {

148 write (STATUS, status);

48

149 dprintf ("STATUS Register Updated\n");

150 }

151 //!Generic instruction behavior method.

152 void ac_behavior (instruction)

153 {

154 dprintf ("PC= 0x%x \n", (int) ac_pc);

155 ac_pc = ac_pc + 2;

156 dprintf

157 ("Instruction number ********************************************=

%X \n",

158 ac_instr_counter);

159 read_status ();

160 };

161 //! Instruction Format behavior methods.

162 void ac_behavior (Format_Byte)

163 {

164 //Empty

165 }

166 void ac_behavior (Format_Bit)

167 {

168 //Empty

169 }

170 void ac_behavior (Format_Literal)

171 {

172 //Empty

173 }

174 void ac_behavior (Format_Control)

175 {

176 //Empty

177 }

49

178 //---------------------------------------------------------------------

179 //---------Byte-Oriented File Register Operations----------------------

180 //---------------------------------------------------------------------

181 //!Instruction ADDWF behavior method.

182 void ac_behavior (ADDWF)

183 {

184 dprintf ("%s 0x%x,%X \n", get_name (), f, d);

185 char result;

186 result = read (f) + W.read ();

187 status[C] = carry_out (read (f), W.read ());

188 status[DC] = digit_carry_out (read (f), W.read ());

189 if (d == 1)

190 {

191 write (f, result);

192 }

193 else

194 {

195 W.write (result);

196 }

197 status[Z] = (result == 0);

198 write_status ();

199 dprintf ("Result: %X \n\n", result);

200 }

201 //!Instruction ANDWF behavior method.

202 void ac_behavior (ANDWF)

203 {

204 dprintf ("%s 0x%x,0x%x \n", get_name (), f, d);

205 char result;

206 result = W.read () & read (f);

50

207 if (d == 1)

208 {


210 }

211 else

212 {


214 }




218 }

219 //!Instruction CLRF behavior method.

220 void ac_behavior (CLRF)

221 {

222 dprintf ("%s 0x%x \n", get_name (), f);

223 write (f, 0);

224 status[Z] = 1;


226 dprintf ("Result: %X \n\n", read (f));

227 }

228 //!Instruction CLRW behavior method.

229 void ac_behavior (CLRW)

230 {

231 dprintf ("%s\n", get_name ());

232 W.write (0);

233 status[Z] = 1;


51

235 dprintf ("Result: %X \n\n", W.read ());

236 }

237 //!Instruction COMF behavior method.

238 void ac_behavior (COMF)

239 {


241 char result;

242 result = ~read (f);

243 if (d == 1)

244 {


246 }

247 else

248 {


250 }




254 }

255 //!Instruction DECF behavior method.

256 void ac_behavior (DECF)

257 {


259 char result;

260 result = read (f) - 1;

261 if (d == 1)

262 {


52

264 }

265 else

266 {


268 }




272 }

273 //!Instruction DECFSZ behavior method.

274 void ac_behavior (DECFSZ)

275 {


277 char result;

278 result = read (f) - 1;

279 if (d == 1)

280 {


282 }

283 else

284 {


286 }

287 if (result == 0)

288 {

289 ac_pc += 2;

290 dprintf ("Result=0. Skip next instruction.\n");

291 }

292 else

293 {

294 dprintf ("Result=1. Run next instrucao! \n");

53

295 }


297 }

298 //!Instruction INCF behavior method.

299 void ac_behavior (INCF)

300 {


302 char result;

303 result = read (f) + 1;

304 if (d == 1)

305 {


307 }

308 else

309 {


311 }




315 }

316 //!Instruction INCFSZ behavior method.

317 void ac_behavior (INCFSZ)

318 {


320 char result;

321 result = read (f) + 1;

322 if (d == 1)

323 {

54


325 }

326 else

327 {


329 }


331 {

332 ac_pc += 2;

333 dprintf ("Result=0. Skip next instruction. \n");

334 }

335 else

336 {

337 dprintf ("Result=1. Run next instruction. \n");

338 }


340 }

341 //!Instruction IORWF behavior method.

342 void ac_behavior (IORWF)

343 {


345 char result;

346 result = W.read () | read (f);

347 if (d == 1)

348 {


350 }

351 else

352 {


354 }

55




358 }

359 //!Instruction MOVF behavior method.

360 void ac_behavior (MOVF)

361 {


363 char result;

364 result = read (f);

365 if (d == 1)

366 {


368 }

369 else

370 {


372 }




376 }

377 //!Instruction MOVWF behavior method.

378 void ac_behavior (MOVWF)

379 {

380 dprintf ("%s 0x%x\n", get_name (), f);

381 write (f, W.read ());

382 dprintf ("Result: %X \n\n", read (f));

56

383 }

384 //!Instruction NOP behavior method.

385 void ac_behavior (NOP)

386 {

387 dprintf ("%s\n\n", get_name ());

388 }

389 //!Instruction RLF behavior method.

390 void ac_behavior (RLF)

391 {


393 unsigned char result;



396 sc_uint < 8 > aux_carry;

397 aux_carry = result;

398 result = (result << 1) | status[C];

399 if (d == 1)

400 {


402 }

403 else

404 {


406 }

407 status[C] = aux_carry[7];



410 }

411 //!Instruction RRF behavior method.

57

412 void ac_behavior (RRF)

413 {


415 unsigned char result;



418 sc_uint < 8 > aux_carry;

419 aux_carry = result;

420 result = (result >> 1) | (status[C] << 7);

421 if (d == 1)

422 {


424 }

425 else

426 {


428 }

429 status[C] = aux_carry[0];



432 }

433 //Instruction SUBWF behavior method.

434 void ac_behavior (SUBWF)

435 {


437 dprintf ("%X - %X\n", read (f), W.read ());

438 char result;

439 result = read (f) - W.read ();

440 status[C] = not_borrow (read (f), W.read ());

441 status[DC] = not_digit_borrow (read (f), W.read ());

58


443 if (d == 1)

444 {


446 }

447 else

448 {


450 }



453 }

454 //!Instruction SWAPF behavior method.

455 void ac_behavior (SWAPF)

456 {


458 char high, low, result;

459 high = read (f) << 4;

460 low = read (f) >> 4;

461 dprintf ("New Values: HIGH: %X LOW: %X \n", high, low);

462 result = high | low;

463 if (d == 1)

464 {


466 }

467 else

468 {


470 }


472 }

59

473 //!Instruction XORWF behavior method.

474 void ac_behavior (XORWF)

475 {


477 char result;

478 result = W.read () ^ read (f);

479 if (d == 1)

480 {


482 }

483 else

484 {

485 W.write (W.read () ^ read (f));

486 }




490 }

491 //---------------------------------------------------------------------

492 //---------Bit Oriented File Register Operations-----------------------

493 //---------------------------------------------------------------------

494 //!Instruction BCF behavior method.

495 void ac_behavior (BCF)

496 {

497 dprintf ("%s 0x%x,%X \n", get_name (), f, b);

498 char result, mask;

499 mask = 0x01 << b;

500 mask = ~mask;

60


502 result = result & mask;



505 }

506 //!Instruction BSF behavior method.

507 void ac_behavior (BSF)

508 {



511 mask = 0x01 << b;


513 result = result | mask;



516 }

517 //!Instruction BTFSC behavior method.

518 void ac_behavior (BTFSC)

519 {



522 mask = 0x01 << b;

523 result = read (f) & mask;


525 {

526 dprintf ("Bit %X = 0. Skip next instruction.\n", b);

527 ac_pc += 2;

528 }

61

529 else

530 {

531 dprintf ("Bit %X = 1. Run next instruction.\n", b);

532 }


534 }

535 //!Instruction BTFSS behavior method.

536 void ac_behavior (BTFSS)

537 {



540 mask = 0x01 << b;

541 result = read (f) & mask;

542 if (result != 0)

543 {

544 dprintf ("Bit %X = 1. Skip next instruction. \n", b);

545 ac_pc += 2;

546 }

547 else

548 {

549 dprintf ("Bit %X = 0. Run next instruction. \n", b);

550 }


552 }

553 //---------------------------------------------------------------------

554 //---------------------------------------------------------------------

555 //---------Literal Operations------------------------------------------

556 //---------------------------------------------------------------------

557 //!Instruction ADDLW behavior method.

62

558 void ac_behavior (ADDLW)

559 {

560 dprintf ("%s %X\n", get_name (), k);

561 char result;

562 result = W.read () + k;

563 status[C] = carry_out (W.read (), k);

564 status[DC] = digit_carry_out (W.read (), k);





569 }

570 //!Instruction ANDLW behavior method.

571 void ac_behavior (ANDLW)

572 {


574 char result;

575 result = W.read () & k;





580 }

581 //!Instruction CLRWDT behavior method.

582 void ac_behavior (CLRWDT)

583 {

584 //Empty

585 }

63

586 //!Instruction IORLW behavior method.

587 void ac_behavior (IORLW)

588 {


590 char result;

591 result = W.read () | k;





596 }

597 //!Instruction MOVLW behavior method.

598 void ac_behavior (MOVLW)

599 {


601 W.write (k);


603 }

604 //!Instruction SUBLW ehavior method.

605 void ac_behavior (SUBLW)

606 {


608 char result;

609 result = k - W.read ();

610 status[C] = not_borrow (k, W.read ());

611 status[DC] = not_digit_borrow (k, W.read ());


64




616 }

617 //!Instruction XORLW behavior method.

618 void ac_behavior (XORLW)

619 {


621 char result;

622 result = W.read () ^ k;





627 }

628 //!Instruction RETLW behavior method.

629 void ac_behavior (RETLW)

630 {


632 W.write (k);

633 ac_pc = STACK.pop ();


635 }

636 //---------------------------------------------------------------------

637 //---------------------------------------------------------------------

638 //---------Control Operations------------------------------------------

65

639 //---------------------------------------------------------------------

640 //!Instruction CALL behavior method.

641 void ac_behavior (CALL)

642 {

643 dprintf ("%s 0x%x\n", get_name (), kaddress);

644 STACK.push (ac_pc);

645 ac_pc = kaddress;

646 dprintf ("Value of PC in stack = 0x%x \n\n", STACK.top ());

647 }

648 //!Instruction GOTO behavior method.

649 void ac_behavior (GOTO)

650 {

651 dprintf ("%s 0x%x\n", get_name (), kaddress);

652 dprintf ("\t\t\t\t STATE: %X ", read (15));

653 ac_pc = kaddress;

654 dprintf ("Branch PC to value = 0x%x \n\n", (unsigned int) ac_pc);

655 }

656 //!Instruction RETFIE behavior method.

657 void ac_behavior (RETFIE)

658 {


660 //Empty


662 }

66

663 //!Instruction RETURN behavior method.

664 void ac_behavior (RETURN)

665 {


667 ac_pc = STACK.pop ();


669 }

670 //!Instruction SLEEP behavior method.

671 void ac_behavior (SLEEP)

672 {

673 //Empty

674 }

675 //---------------------------------------------------------------------

67

A.5 pic16F84 ca.ac

1 /********************************************************


3 * *

4 * Author: *


6 * *



9 *******************************************************/

10 AC_ARCH(pic16F84_ca){

11 ac_mem MEM:5M;

12 ac_regbank BANK:256;

13 ac_wordsize 8;

14 ac_reg W;

15 ac_format Fmt_IF_ID = "%pc:32 %pc_write:1";

16 ac_format Fmt_ID_EX = "%write_enable:1 %reg_target:1 %reg_address:7

%op_A:8 %op_B:8 %zero_enable:1 %carry_enable:1 %digit_carry_enable:1";

17 ac_format Fmt_EX_WB = "%alu_result:8 %flush:1 %write_enable:1

%reg_target:1 %reg_address:7 %zero_enable:1 %carry:1 %carry_enable:1

%digit_carry:1 %digit_carry_enable:1";

18 ac_reg<Fmt_IF_ID> IF_ID;

19 ac_reg<Fmt_ID_EX> ID_EX;

20 ac_reg<Fmt_EX_WB> EX_WB;

21 ac_pipe pipe = {IF, ID, EX, WB};

22 ARCH_CTOR(pic16F84_ca) {

23 ac_isa("pic16F84_ca_isa.ac");

24 set_endian("big");

25 };

26 };

68

A.6 pic16F84 ca isa.ac

1 /*******************************************************


3 * *

4 * Author: *


6 * *



9 *******************************************************/

/*

10 NOTE 1: We consider instruction word as 8 bits size, and for this PC is

11 increased by 2 instead of 1 and insruction addresses are multipled

12 by 2. We needed add 2 dummy bits at begin of instruction to become

13 the instruction word size a two power with 16 bits.

14 NOTE 2: For Literal and Control operations, we replaceed "don’t care’s"

15 for "zeros" in order to keep instruction formats as

16 simple as possible.

*/

17 AC_ISA(pic16F84_ca){

18 //Format Declarations--------------------------------------------------

19 ac_format Format_Byte = "%dummy:2 %opbyte:6 %d:1 %f:7";

20 ac_format Format_Bit = "%dummy:2 %opbit:4 %b:3 %f:7";

21 ac_format Format_Literal = "%dummy:2 %oplit:6 %k:8";

22 ac_format Format_Control = "%dummy:2 %opctrl:3 %kaddress:11";

23 //---------------------------------------------------------------------

24 //Associations of Formats with instructions----------------------------

25 ac_instr<Format_Byte> CLRWDT, CLRW, CLRF, ADDWF, MOVWF, ANDWF, DECF,

INCF, MOVF, NOP, IORWF, SUBWF, XORWF, COMF, DECFSZ, INCFSZ, RLF, RRF, SWAPF,

69

RETURN, RETFIE, SLEEP;

26 ac_instr<Format_Bit> BCF, BSF, BTFSC, BTFSS;

27 ac_instr<Format_Literal > MOVLW,ANDLW,IORLW,XORLW, ADDLW, SUBLW, RETLW;

28 ac_instr<Format_Control> GOTO, CALL;

29 //---------------------------------------------------------------------

30 //Addresses Modes------------------------------------------------------

31 //ac_addr_mode_A GOTO(kaddress);

32 //ac_addr_mode_A CALL(kaddress);

33 //Assembly e Decoder of Instructions-----------------------------------

34 ISA_CTOR(pic16F84_ca){

35 //Byte-Oriented File Register Operations---------------------------

36 ADDWF.set_asm("ADDWF %f, %d");

37 ADDWF.set_decoder(opbyte=0x07);

38 ADDWF.set_cycles(1);

39 ANDWF.set_asm("ANDWF %f, %d");

40 ANDWF.set_decoder(opbyte=0x05);

41 ANDWF.set_cycles(1);

42 CLRF.set_asm("CLRF %f");

43 CLRF.set_decoder(opbyte=0x01, d=1);

44 CLRF.set_cycles(1);

45 CLRW.set_asm("CLRW");

46 CLRW.set_decoder(opbyte=0x01, d=0);

47 CLRW.set_cycles(1);

48 COMF.set_asm("COMF %f, %d");

49 COMF.set_decoder(opbyte=0x09);

50 COMF.set_cycles(1);

51 DECF.set_asm("DECF %f, %d");

70

52 DECF.set_decoder(opbyte=0x03);

53 DECF.set_cycles(1);

54 DECFSZ.set_asm("DECFSZ %f, %d");

55 DECFSZ.set_decoder(opbyte=0x0B);

56 DECFSZ.set_cycles(1);

57 INCF.set_asm("INCF %f, %d");

58 INCF.set_decoder(opbyte=0x0A);

59 INCF.set_cycles(1);

60 INCFSZ.set_asm("INCFSZ %f, %d");

61 INCFSZ.set_decoder(opbyte=0x0F);

62 INCFSZ.set_cycles(1);

63 IORWF.set_asm("IORWF %f, %d");

64 IORWF.set_decoder(opbyte=0x04);

65 IORWF.set_cycles(1);

66 MOVF.set_asm("MOVF %f, %d");

67 MOVF.set_decoder(opbyte=0x08);

68 MOVF.set_cycles(1);

69 MOVWF.set_asm("MOVWF %f");

70 MOVWF.set_decoder(opbyte=0x00, d=1);

71 MOVWF.set_cycles(1);

72 NOP.set_asm("NOP");

73 NOP.set_decoder(opbyte=0x00, d=0, f=0x00);

74 NOP.set_cycles(1);

75 RLF.set_asm("RLF %f, %d");

76 RLF.set_decoder(opbyte=0x0D);

77 RLF.set_cycles(1);

71

78 RRF.set_asm("RRF %f, %d");

79 RRF.set_decoder(opbyte=0x0C);

80 RRF.set_cycles(1);

81 SUBWF.set_asm("SUBWF %f, %d");

82 SUBWF.set_decoder(opbyte=0x02);

83 SUBWF.set_cycles(1);

84 SWAPF.set_asm("SWAPF %f, %d");

85 SWAPF.set_decoder(opbyte=0x0E);

86 SWAPF.set_cycles(1);

87 XORWF.set_asm("XORWF %f, %d");

88 XORWF.set_decoder(opbyte=0x06);

89 XORWF.set_cycles(1);

90 //-----------------------------------------------------------------

91 //Bit-Oriented File Register Operations----------------------------

92 BCF.set_asm("BCF %f, %b");

93 BCF.set_decoder(opbit=0x04);

94 BCF.set_cycles(1);

95 BSF.set_asm("BSF %f, %b");

96 BSF.set_decoder(opbit=0x05);

97 BSF.set_cycles(1);

98 BTFSC.set_asm("BTFSC %f, %b");

99 BTFSC.set_decoder(opbit=0x06);

00 BTFSC.set_cycles(1);

01 BTFSS.set_asm("BTFSS %f, %b");

02 BTFSS.set_decoder(opbit=0x07);

03 BTFSS.set_cycles(1);

04 //-----------------------------------------------------------------

72

05 //Literal Operations-----------------------------------------------

06 ADDLW.set_asm("ADDLW %k");

07 ADDLW.set_decoder(oplit=0x3E);

08 ADDLW.set_cycles(1);

09 ANDLW.set_asm("ANDLW %k");

10 ANDLW.set_decoder(oplit=0x39);

11 ANDLW.set_cycles(1);


13 CLRWDT.set_asm("CLRWDT");

14 CLRWDT.set_decoder(opbyte=0x00, d=0, f=0x64);

15 CLRWDT.set_cycles(1);

16 IORLW.set_asm("IORLW %k");

17 IORLW.set_decoder(oplit=0x38);

18 IORLW.set_cycles(1);

19 MOVLW.set_asm("MOVLW %k");

20 MOVLW.set_decoder(oplit=0x30);

21 MOVLW.set_cycles(1);

22 SUBLW.set_asm("SUBLW %k");

23 SUBLW.set_decoder(oplit=0x3C);

24 SUBLW.set_cycles(1);

25 XORLW.set_asm("XORLW %k");

26 XORLW.set_decoder(oplit=0x3A);

27 XORLW.set_cycles(1);

28 RETLW.set_asm("RETLW %k");

29 RETLW.set_decoder(oplit=0x34);

30 RETLW.set_cycles(1);

73

31 //-----------------------------------------------------------------

32 //Control Operations-----------------------------------------------

33 CALL.set_asm("CALL %kaddress");

34 CALL.set_decoder(opctrl=0x04);

35 CALL.set_cycles(1);

36 GOTO.set_asm("GOTO %kaddress");

37 GOTO.set_decoder(opctrl=0x05);

38 GOTO.set_cycles(1);


40 RETFIE.set_asm("RETFIE");

41 RETFIE.set_decoder(opbyte=0x0, d=0, f=0x09);

42 RETFIE.set_cycles(1);


44 RETURN.set_asm("RETURN");

45 RETURN.set_decoder(opbyte=0x00, d=0, f=0x08);

46 RETURN.set_cycles(1);


48 SLEEP.set_asm("SLEEP");

49 SLEEP.set_decoder(opbyte=0x0, d=0, f=0x63);

50 SLEEP.set_cycles(1);

51 //-----------------------------------------------------------------

52 };

53 };

74

A.7 pic16F84 ca-isa.cpp

1 /*******************************************************


3 * *

4 * Author: *


6 * *



9 *******************************************************/

10 #include "pic16F84_ca-isa.H"

11 #include "ac_isa_init.cpp"

12 #include "constants.h"

13 //Level of debug

14 #define PRINT_DEBUG_LEVEL 5

15 //Level of debug for stack operations

16 #define STACK_DEBUG_LEVEL 2

17 //Level of debug for print bits of status register

18 #define PRINT_STATUS_LEVEL 2

19 //Level of debug for print PC value and number of executed instructions

20 #define PC_LEVEL 2

21 //Level of debug for print the instruction on insctruction fetch stage

22 #define IF_STAGE_LEVEL 2

23 //Level of debug for print the instruction on decodification stage

24 #define ID_STAGE_LEVEL 2

25 //Level of debug for print the instruction on execution stage

26 #define EX_STAGE_LEVEL 2

27 //Level of debug for print the instruction on write back stage

28 #define WB_STAGE_LEVEL 2

29 //Level of debug for print the result wrinte on write back stage

30 #define RESULT_LEVEL 1

75

31 //Uncomment this line to view the debug model

32 #define DEBUG_MODEL

33 #ifdef DEBUG_MODEL

34 #include <stdio.h>

35 #include <stdarg.h>

36 int dprintf(const unsigned int level, const char *format, ...)

37 {

38 if (level <= PRINT_DEBUG_LEVEL)

39 {

40 int ret;

41 va_list args;

42 va_start(args, format);

43 ret = vfprintf(stderr, format, args);

44 va_end(args);

45 return ret;

46 }

47 else

48 {

49 return 0;

50 }

51 }

52 #else

53 inline void dprintf(const unsigned int level, const char *format, ...) {}

54 #endif

55 //Auxiliar Status Register

56 sc_uint<8> status;

57 /**

58 * Stack of instruciton addresses.

59 */

76

60 class {

61 private:

62 char tos;

63 int addresses[8];

64 public:

65 void push(int address) {

66 dprintf(STACK_DEBUG_LEVEL, "Push %i on position 0x%X of

Stack\n", address, tos);

67 addresses[tos] = address;

68 tos = (tos + 1) % 8;

69 }

70 int pop() {

71 tos = (tos + 7) % 8;

72 dprintf(STACK_DEBUG_LEVEL, "Pop %i on position 0x%X of

Stack\n", addresses[tos], tos);

73 return addresses[tos];

74 }

75 int top() {

76 return addresses[(tos + 7) % 8];

77 }

78 } STACK;

79 /**

80 * Method for read a register from reg bank.

81 */

82 ac_word read( unsigned address )

83 {


85 {

86 address = BANK.read(FSR);

87 }

88 return BANK.read(address);

77

89 }

90 /**

91 * Method for write a register from reg bank.

92 */

93 void write( unsigned address, ac_word datum )

94 {


96 {

97 address = BANK.read(FSR);

98 }

99 BANK.write(address, datum);

100 }

101 /**

102 * Method for verify if there is or not a carry out.

103 */

104 bool carry_out(char value1, char value2)

105 {

106 if ((value1 < 0) && (value2 < 0))

107 {

108 return true;

109 }

110 else

111 {

112 if ( !((value1 >= 0) && (value2 >= 0)) )

113 {

114 if (value2 >= -value1)

115 return true;

116 }

117 }

118 return false;

119 }

78

120 /**

121 * Method for verify if there is or not a digit carry out.

122 */

123 bool digit_carry_out(char value1, char value2)

124 {

125 char sum;

126 bool carry_out;

127 value1 &= 0x0F;

128 value2 &= 0x0F;

129 sum = value1 + value2;

130 carry_out = sum >> 4;

131 return carry_out;

132 }

133 /**

134 * Negative method for verify if there is or not a borrow.

135 */

136 bool inline not_borrow(char value1, char value2)

137 {

138 return ((unsigned char)value1 >= (unsigned char)value2);

139 }

140 /**

141 * Negative method for verify if there is or not a digit borrow.

142 */

143 bool inline not_digit_borrow(char value1, char value2)

144 {

145 return not_borrow(value1 << 4, value2 << 4);

146 }

147 //!Generic instruction behavior method.

79

148 void ac_behavior( instruction ){

149 static unsigned int instr_number = 0;

150 switch (stage)

151 {

152 case IF:

153 dprintf(PC_LEVEL, "PC= 0x%x\n", (unsigned int)ac_pc);

154 //If the write on PC is enable and the instruction will not

be flush then

155 //write on PC

156 if ((IF_ID.pc_write == ENABLE) && (EX_WB.flush == UNABLE))

157 {

158 ac_pc = IF_ID.pc;

159 }

160 else

161 {

162 ac_pc = ac_pc + 2;

163 }

164 //Disable writting on PC

165 IF_ID.pc_write = UNABLE;

166 //Disable flush

167 EX_WB.flush = UNABLE;

168 break;

169 case ID:

170 ID_EX.write_enable = UNABLE;

171 ID_EX.zero_enable = UNABLE;

172 ID_EX.carry_enable = UNABLE;

173 ID_EX.digit_carry_enable = UNABLE;

174 //Verify if a forwarding is needed

175 if (EX_WB.write_enable && (EX_WB.reg_target == W_TARGET))

176 {

177 ID_EX.op_B = EX_WB.alu_result;

178 }

179 else

180 {

80

181 ID_EX.op_B = W.read();

182 }

183 break;

184 case EX:

185 EX_WB.write_enable = ID_EX.write_enable;

186 EX_WB.reg_target = ID_EX.reg_target;

187 EX_WB.reg_address = ID_EX.reg_address;

188 EX_WB.zero_enable = ID_EX.zero_enable;

189 EX_WB.carry_enable = ID_EX.carry_enable;

190 EX_WB.digit_carry_enable = ID_EX.digit_carry_enable;

191 break;

192 case WB:

193 dprintf(PC_LEVEL, "Instruction number

********************************************= %X \n", instr_number++);

194 //Verify if the write is enable

195 if (EX_WB.write_enable == ENABLE)

196 {

197 //Verify if the target is the acumulator

198 if (EX_WB.reg_target == W_TARGET)

199 {

200 //Write in the acumulator

201 W.write(EX_WB.alu_result);

202 dprintf(RESULT_LEVEL, "Result (%i OR 0x%X) was

written on acumulator\n", (int)EX_WB.alu_result, (int)EX_WB.alu_result);

203 }

204 else

205 {

206 //Write in the target register

207 write(EX_WB.reg_address, EX_WB.alu_result);

208 dprintf(RESULT_LEVEL, "Result (%i OR 0x%X) was

written in register 0x%X\n", (int)EX_WB.alu_result, (int)EX_WB.alu_result,

(int)EX_WB.reg_address);

209 }

210 }

81

211 //Read the status value

212 status = read(STATUS);

213 //Verify if the zero write is enable

214 if (EX_WB.zero_enable == ENABLE)

215 {

216 char result = (char)EX_WB.alu_result;


218 }

219 //Verify if the carry write is enable

220 if (EX_WB.carry_enable == ENABLE)

221 {

222 status[C] = EX_WB.carry;

223 }

224 //Verify if the digit carry write is enable

225 if (EX_WB.digit_carry_enable == ENABLE)

226 {

227 status[DC] = EX_WB.digit_carry;

228 }

229 write(STATUS, status);

230 dprintf(PRINT_STATUS_LEVEL, "Current Value of STATUS

Register: %X \nBITS: \n", (int)status);

231 dprintf(PRINT_STATUS_LEVEL, "Z DC C\n");

232 dprintf(PRINT_STATUS_LEVEL, "%d %d %d\n", (status[Z] ==

1?1:0), (status[DC] == 1?1:0), (status[C] == 1?1:0));

233 break;

234 }

235 };

236 //! Instruction Format behavior methods.

237 void ac_behavior( Format_Byte ){

82

238 if (stage == ID)

239 {

240 ID_EX.reg_target = d;

241 ID_EX.reg_address = f;

242 //Verify if a forwarding is needed

243 if (EX_WB.write_enable && (EX_WB.reg_target == REG_TARGET) &&

244 (EX_WB.reg_address == f))

245 {

246 ID_EX.op_A = EX_WB.alu_result;

247 }

248 else

249 {

250 ID_EX.op_A = read(f);

251 }

252 }

253 }

254 void ac_behavior( Format_Bit ){


256 {

257 ID_EX.reg_target = REG_TARGET;

258 ID_EX.reg_address = f;

259 ID_EX.op_A = read(f);

260 }

261 }

262 void ac_behavior( Format_Literal ){


264 {

265 ID_EX.reg_target = W_TARGET;

266 }

267 }

268 void ac_behavior( Format_Control ){

269 //Empty

83

270 }

271 //!Instruction CLRWDT behavior method.

272 void ac_behavior( CLRWDT ){

273 switch (stage)

274 {

275 case IF:

276 dprintf(IF_STAGE_LEVEL, "IF stage: %s\n", get_name());

277 break;

278 case ID:

279 dprintf(ID_STAGE_LEVEL, "ID stage: %s\n", get_name());

280 break;

281 case EX:

282 dprintf(EX_STAGE_LEVEL, "EX stage: %s\n", get_name());

283 break;

284 case WB:

285 dprintf(WB_STAGE_LEVEL, "WB stage: %s\n", get_name());

286 break;

287 }

288 }

289 //!Instruction CLRW behavior method.

290 void ac_behavior( CLRW ){

291 switch (stage)

292 {

293 case IF:


295 break;

296 case ID:


298 ID_EX.write_enable = ENABLE;

299 ID_EX.zero_enable = ENABLE;

300 break;

301 case EX:


84

303 EX_WB.alu_result = 0;

304 break;

305 case WB:


307 break;

308 }

309 }

310 //!Instruction CLRF behavior method.

311 void ac_behavior( CLRF ){

312 switch (stage)

313 {

314 case IF:

315 dprintf(IF_STAGE_LEVEL, "IF stage: %s 0x%X\n", get_name(),

f);

316 break;

317 case ID:

318 dprintf(ID_STAGE_LEVEL, "ID stage: %s 0x%X\n", get_name(),

f);



321 break;

322 case EX:

323 dprintf(EX_STAGE_LEVEL, "EX stage: %s 0x%X\n", get_name(),

f);

324 EX_WB.alu_result = 0;

325 break;

326 case WB:

327 dprintf(WB_STAGE_LEVEL, "WB stage: %s 0x%X\n", get_name(),

f);

328 break;

329 }

330 }

331 //!Instruction ADDWF behavior method.

85

332 void ac_behavior( ADDWF ){

333 switch (stage)

334 {

335 case IF:

336 dprintf(IF_STAGE_LEVEL, "IF stage: %s 0x%X,%d\n", get_name(),

f, d);

337 break;

338 case ID:

339 dprintf(ID_STAGE_LEVEL, "ID stage: %s 0x%X,%d\n", get_name(),

f, d);



342 ID_EX.carry_enable = ENABLE;

343 ID_EX.digit_carry_enable = ENABLE;

344 break;

345 case EX:

346 dprintf(EX_STAGE_LEVEL, "EX stage: %s 0x%X,%d\n", get_name(),

f, d);

347 EX_WB.alu_result = read(f) + W.read();

348 EX_WB.carry = carry_out(read(f), W.read());

349 EX_WB.digit_carry = digit_carry_out(read(f), W.read());

350 break;

351 case WB:

352 dprintf(WB_STAGE_LEVEL, "WB stage: %s 0x%X,%d\n", get_name(),

f, d);

353 break;

354 }

355 }

356 //!Instruction MOVWF behavior method.

357 void ac_behavior( MOVWF ){

358 switch (stage)

359 {

360 case IF:


86

f, d);

362 break;

363 case ID:


f, d);


366 break;

367 case EX:


f, d);

369 EX_WB.alu_result = W.read();

370 break;

371 case WB:


f, d);

373 break;

374 }

375 }

376 //!Instruction ANDWF behavior method.

377 void ac_behavior( ANDWF ){

378 switch (stage)

379 {

380 case IF:


f, d);

382 break;

383 case ID:


f, d);



387 break;

388 case EX:


87

f, d);

390 EX_WB.alu_result = read(f) & W.read();

391 break;

392 case WB:


f, d);

394 break;

395 }

396 }

397 //!Instruction DECF behavior method.

398 void ac_behavior( DECF ){

399 switch (stage)

400 {

401 case IF:


f, d);

403 break;

404 case ID:


f, d);



408 break;

409 case EX:


f, d);

411 EX_WB.alu_result = read(f) - 1;

412 break;

413 case WB:


f, d);

415 break;

416 }

417 }

88

418 //!Instruction INCF behavior method.

419 void ac_behavior( INCF ){

420 switch (stage)

421 {

422 case IF:


f, d);

424 break;

425 case ID:


f, d);



429 break;

430 case EX:


f, d);

432 EX_WB.alu_result = read(f) + 1;

433 break;

434 case WB:


f, d);

436 break;

437 }

438 }

439 //!Instruction MOVF behavior method.

440 void ac_behavior( MOVF ){

441 switch (stage)

442 {

443 case IF:


f, d);

445 break;

89

446 case ID:


f, d);



450 break;

451 case EX:


f, d);

453 EX_WB.alu_result = read(f);

454 break;

455 case WB:


f, d);

457 break;

458 }

459 }

460 //!Instruction NOP behavior method.

461 void ac_behavior( NOP ){

462 switch (stage)

463 {

464 case IF:


466 break;

467 case ID:


469 break;

470 case EX:


472 break;

473 case WB:


475 break;

90

476 }

477 }

478 //!Instruction IORWF behavior method.

479 void ac_behavior( IORWF ){

480 switch (stage)

481 {

482 case IF:


f, d);

484 break;

485 case ID:


f, d);



489 break;

490 case EX:


f, d);

492 EX_WB.alu_result = read(f) | W.read();

493 break;

494 case WB:


f, d);

496 break;

497 }

498 }

499 //!Instruction SUBWF behavior method.

500 void ac_behavior( SUBWF ){

501 switch (stage)

502 {

503 case IF:


91

f, d);

505 break;

506 case ID:


f, d);





512 break;

513 case EX:


f, d);

515 EX_WB.alu_result = read(f) - W.read();

516 EX_WB.carry = not_borrow(read(f), W.read());

517 EX_WB.digit_carry = not_digit_borrow(read(f), W.read());

518 break;

519 case WB:


f, d);

521 break;

522 }

523 }

524 //!Instruction XORWF behavior method.

525 void ac_behavior( XORWF ){

526 switch (stage)

527 {

528 case IF:


f, d);

530 break;

531 case ID:


f, d);

92



535 break;

536 case EX:


f, d);

538 EX_WB.alu_result = read(f) ^ W.read();

539 break;

540 case WB:


f, d);

542 break;

543 }

544 }

545 //!Instruction COMF behavior method.

546 void ac_behavior( COMF ){

547 switch (stage)

548 {

549 case IF:


f, d);

551 break;

552 case ID:


f, d);



556 break;

557 case EX:


f, d);

559 EX_WB.alu_result = ~read(f);

560 break;

561 case WB:

93


f, d);

563 break;

564 }

565 }

566 //!Instruction DECFSZ behavior method.

567 void ac_behavior( DECFSZ ){

568 switch (stage)

569 {

570 case IF:


f, d);

572 break;

573 case ID:


f, d);


576 break;

577 case EX:


f, d);

579 EX_WB.alu_result = read(f) - 1;

580 if (EX_WB.alu_result == 0)

581 {

582 //Skip if zero

583 ac_flush("ID");

584 EX_WB.flush = ENABLE;

585 }

586 break;

587 case WB:


f, d);

589 break;

590 }

94

591 }

592 //!Instruction INCFSZ behavior method.

593 void ac_behavior( INCFSZ ){

594 switch (stage)

595 {

596 case IF:


f, d);

598 break;

599 case ID:


f, d);


602 break;

603 case EX:


f, d);

605 EX_WB.alu_result = read(f) + 1;

606 if (EX_WB.alu_result == 0)

607 {

608 //Skip if zero

609 ac_flush("ID");


611 }

612 break;

613 case WB:


f, d);

615 break;

616 }

617 }

618 //!Instruction RLF behavior method.

619 void ac_behavior( RLF ){

95

620 sc_uint<8> f_value;

621 switch (stage)

622 {

623 case IF:


f, d);

625 break;

626 case ID:


f, d);



630 break;

631 case EX:


f, d);

633 f_value = read(f);

634 EX_WB.alu_result = (f_value << 1) | status[C];

635 EX_WB.carry = f_value[7];

636 break;

637 case WB:


f, d);

639 break;

640 }

641 }

642 //!Instruction RRF behavior method.

643 void ac_behavior( RRF ){


645 switch (stage)

646 {

647 case IF:


f, d);

96

649 break;

650 case ID:


f, d);



654 break;

655 case EX:


f, d);


658 EX_WB.alu_result = (f_value >> 1) | (status[C] << 7);

659 EX_WB.carry = f_value[0];

660 break;

661 case WB:


f, d);

663 break;

664 }

665 }

666 //!Instruction SWAPF behavior method.

667 void ac_behavior( SWAPF ){

668 unsigned char f_value;

669 switch (stage)

670 {

671 case IF:


f, d);

673 break;

674 case ID:


f, d);


677 break;

97

678 case EX:


f, d);


681 EX_WB.alu_result = (f_value << 4) | (f_value >> 4);

682 break;

683 case WB:


f, d);

685 break;

686 }

687 }

688 //!Instruction RETURN behavior method.

689 void ac_behavior( RETURN ){

690 switch (stage)

691 {

692 case IF:


694 break;

695 case ID:


697 //Write in PC

698 IF_ID.pc_write = ENABLE;

699 IF_ID.pc = STACK.top();

700 break;

701 case EX:


703 ac_flush("ID");


705 //remove the last addres because the return was executed

706 STACK.pop();

707 break;

708 case WB:


98

710 break;

711 }

712 }

713 //!Instruction RETFIE behavior method.

714 void ac_behavior( RETFIE ){

715 switch (stage)

716 {

717 case IF:


719 break;

720 case ID:


722 break;

723 case EX:


725 ac_flush("ID");


727 break;

728 case WB:


730 break;

731 }

732 }

733 //!Instruction SLEEP behavior method.

734 void ac_behavior( SLEEP ){

735 switch (stage)

736 {

737 case IF:


739 break;

740 case ID:


742 break;

99

743 case EX:


745 break;

746 case WB:


748 break;

749 }

750 }

751 //!Instruction BCF behavior method.

752 void ac_behavior( BCF ){


754 switch (stage)

755 {

756 case IF:


f, b);

758 break;

759 case ID:


f, b);


762 break;

763 case EX:


f, b);


766 f_value[b] = CLEAR;

767 EX_WB.alu_result = f_value;

768 break;

769 case WB:


f, b);

771 break;

772 }

100

773 }

774 //!Instruction BSF behavior method.

775 void ac_behavior( BSF ){


777 switch (stage)

778 {

779 case IF:


f, b);

781 break;

782 case ID:


f, b);


785 break;

786 case EX:


f, b);


789 f_value[b] = SET;

790 EX_WB.alu_result = f_value;

791 break;

792 case WB:


f, b );

794 break;

795 }

796 }

797 //!Instruction BTFSC behavior method.

798 void ac_behavior( BTFSC ){


800 switch (stage)

801 {

101

802 case IF:


f, b);

804 break;

805 case ID:


f, b);

807 break;

808 case EX:


f, b);


811 if (f_value[b] == CLEAR)

812 {

813 //Skip if clear

814 ac_flush("ID");


816 }

817 break;

818 case WB:


f, b);

820 break;

821 }

822 }

823 //!Instruction BTFSS behavior method.

824 void ac_behavior( BTFSS ){


826 switch (stage)

827 {

828 case IF:


f, b);

830 break;

102

831 case ID:


f, b);

833 break;

834 case EX:


f, b);


837 if (f_value[b] == SET)

838 {

839 //Skip if set

840 ac_flush("ID");


842 }

843 break;

844 case WB:


f, b);

846 //Empty

847 break;

848 }

849 }

850 //!Instruction MOVLW behavior method.

851 void ac_behavior( MOVLW ){

852 switch (stage)

853 {

854 case IF:


k);

856 //Empty

857 break;

858 case ID:


k);

103


861 break;

862 case EX:


k);

864 EX_WB.alu_result = k;

865 break;

866 case WB:


k);

868 //Empty

869 break;

870 }

871 }

872 //!Instruction ANDLW behavior method.

873 void ac_behavior( ANDLW ){

874 switch (stage)

875 {

876 case IF:


k);

878 //Empty

879 break;

880 case ID:


k);



884 break;

885 case EX:


k);

887 EX_WB.alu_result = k & W.read();

888 break;

104

889 case WB:


k);

891 //Empty

892 break;

893 }

894 }

895 //!Instruction IORLW behavior method.

896 void ac_behavior( IORLW ){

897 switch (stage)

898 {

899 case IF:


k);

901 //Empty

902 break;

903 case ID:


k);



907 break;

908 case EX:


k);

910 EX_WB.alu_result = k | W.read();

911 break;

912 case WB:


k);

914 //Empty

915 break;

916 }

917 }

105

918 //!Instruction XORLW behavior method.

919 void ac_behavior( XORLW ){

920 switch (stage)

921 {

922 case IF:


k);

924 //Empty

925 break;

926 case ID:


k);



930 break;

931 case EX:


k);

933 EX_WB.alu_result = k ^ W.read();

934 break;

935 case WB:


k);

937 //Empty

938 break;

939 }

940 }

941 //!Instruction ADDLW behavior method.

942 void ac_behavior( ADDLW ){

943 switch (stage)

944 {

945 case IF:


106

k);

947 //Empty

948 break;

949 case ID:


k);





955 break;

956 case EX:


k);

958 EX_WB.alu_result = k + W.read();

959 EX_WB.carry = carry_out(k, W.read());

960 EX_WB.digit_carry = digit_carry_out(k, W.read());

961 break;

962 case WB:


k);

964 //Empty

965 break;

966 }

967 }

968 //!Instruction SUBLW behavior method.

969 void ac_behavior( SUBLW ){

970 switch (stage)

971 {

972 case IF:


k);

974 //Empty

975 break;

107

976 case ID:


k);





982 break;

983 case EX:


k);

985 EX_WB.alu_result = k - W.read();

986 EX_WB.carry = not_borrow(k, W.read());

987 EX_WB.digit_carry = not_digit_borrow(k, W.read());

988 break;

989 case WB:


k);

991 //Empty

992 break;

993 }

994 }

995 //!Instruction RETLW behavior method.

996 void ac_behavior( RETLW ){

997 switch (stage)

998 {

999 case IF:


k);

1001 break;

1002 case ID:


k);


108

1005 ID_EX.reg_target = W_TARGET;

1006 //Write in PC


1008 //Get the possible target of branch

1009 IF_ID.pc = STACK.top();

1010 break;

1011 case EX:


k);

1013 EX_WB.alu_result = k;

1014 ac_flush("ID");


1016 //remove the last addres because the return was executed

1017 STACK.pop();

1018 break;

1019 case WB:


k);

1021 break;

1022 }

1023 }

1024 //!Instruction GOTO behavior method.

1025 void ac_behavior( GOTO ){

1026 switch (stage)

1027 {

1028 case IF:


kaddress);

1030 //Empty

1031 break;

1032 case ID:


kaddress);


109

1035 IF_ID.pc = kaddress;

1036 break;

1037 case EX:


kaddress);



1041 break;

1042 case WB:


kaddress);

1044 //Empty

1045 break;

1046 }

1047 }

1048 //!Instruction CALL behavior method.

1049 void ac_behavior( CALL ){

1050 static int old_pc;

1051 switch (stage)

1052 {

1053 case IF:


kaddress);

1055 //Save the PC value

1056 old_pc = ac_pc;

1057 //Empty

1058 break;

1059 case ID:


kaddress);


1062 IF_ID.pc = kaddress;

1063 break;

1064 case EX:

110


kaddress);


1067 //Push the pc value

1068 STACK.push(old_pc);


1070 break;

1071 case WB:


kaddress);

1073 //Empty

1074 break;

1075 }

1076 }

111

APENDICE B -- Artigo

Modelagem do PIC 16F84 para Projeto de SistemasEmbutidos Baseados em Micro-controlador


1Curso de Ciencias da ComputacaoDepartamento de Informatica e Estatıstica – Universidade Federal de Santa Catarina

Caixa Postal 476 – 88040-900 Florianopolis, SC

[email protected]

Abstract. The offer of millions of devices on a single chip combined with thedemand of challenging embedded system applications gave rise to Systems-on-Chip (SoCs). Being an answer to the high non-recurring engineering costs ofadvanced technologies, platform-based design of SoCs relies on a reference ar-chitecture and on IP reuse. Efficient IP reuse requires proper interface designand design space exploration, which assumes efficient IP modeling. This workdescribes two models for popular the PIC 16F84 micro-controller in distinctabstraction levels: one is purely functional while the other is cycle accurate.

1. Introducao

A evolucao da tecnologia dos circuitos integrados, regida pela lei de Moore1 resulta emmilhoes de portas logicas em umaunica pastilha de silıcio. Essa enorme oferta de hard-ware, combinada com a crescente demanda de aplicacoes na industria de sistemas em-barcados, resultou no aparecimento de sistemas integrados de hardware (CPU, memoriae perifericos) e software sob a forma deSystems-on-Chip(SoCs)[Bergamaschi, 2002].

Para reduzir o custo de desenvolvimento e acomodar otime-to-market, o projetode SoCs tende a adotar uma plataforma-alvo [Sangiovanni-Vincentelli and Martin, 2001],ou seja, uma arquitetura de referencia concebida para viabilizar o reuso de seus compo-nentes, chamados de blocos de propriedade intelectual (IPs). Tal plataforma pode entaoser personalizada para uma aplicacao especıfica, atraves da remocao de IPs desnecessariose/ou inclusao de novos IPs.

O processo de personalizacao de uma plataforma requer a exploracao de arqui-teturas alternativas resultantes da selecao de diferentes conjuntos de IPs. Tal exploracaoenvolve a verificacao do comportamento do sistema em face dos requisitos funcionais, aestimativa de desempenho em face de restricoes de tempo real e a estimativa de potenciaem face da necessidade de baixo consumo de energia. Isso requer a disponibilidade demodelos eficientes para cada um dos IPs.

Este trabalho aborda a modelagem eficiente de um IP, em dois nıveis de abstracaodiferentes: um puramente funcional e outro com precisao de ciclos. O IP modelado cor-responde a um micro-controlador de uso bastante difundido na industria, o PIC 16F84.Ambos os modelos foram descritos formalmente, sendo validados atraves de um conjuntode casos de teste.

1A Lei de Moore preve que, a cada 18 meses, dobra o numero de transistores em um circuito integrado(CI).

2. O Micro-controlador PIC

O PICe um micro-controlador inspirado em arquiteturas RISC que adota maquina de Har-vard baseada em acumulador [Patterson and Hennessy, 2003], permitindo que as palavrasde dados e de instrucao possuam tamanhos diferentes, (8 e 14-bits respectivamente).

O acumulador do PICe comumente referenciado por W, notacao que sera dora-vante adotada neste texto.

2.1. Conjunto de instrucoes do PIC

O PIC possui 35 instrucoes que podem ser separadas em 3 diferentes formatos:

• Orientadas a byte: 18 instrucoes podem ser mapeadas para este formato, elaspossuem no maximo dois operandos e operam sobre dados em registradores.

• Orientadas a bit: Apenas 4 instrucoes sao mapeadas para este formato, queagrupa instrucoes para verificacao e alteracao de bits em um dado registrador.E neste formato que se encontram algumas instrucoes de desvio condicional (BitTest f, Skip if Clear - BTFSCeBit Test f, Skip if Set - BTFSS).

• Literal: Neste formato se encontram as operacoes sobre valores imediatos, queoperam o acumulador com um literal contido na propria instrucao. Exemplos deinstrucoes deste formato saoADDLW, ANDLWeMOVLW.

• Controle: As instrucoes mapeadas para este formato sao responsaveis, dentreoutras operacoes de controle, pelas operacoes de desvio incondicional (GOTO),chamada e retorno de procedimento (CALL, RETURN, RETLW) e ainda retornode interrupcao (RETFIE).

3. Modelagem Funcional

A modelagem funcional de um sistema nao considera como este sistema sera implemen-tado. Somente o comportamento da correlacao entre entradas e saıdase relevante nestenıvel de abstracao.

Para descrever o micro-controlador PIC, foi utilizada uma linguagem de descricaode arquitetura (ADL), que sera brevemente introduzida na secao seguinte.

3.1. A linguagem de descricao de arquiteturas adotada

ArchC e uma linguagem de descricao de arquitetura que foi desenvolvida no Laboratoriode Sistemas Computacionais (LSC) do Instituto de Computacao da Universidade de Cam-pinas (IC/UNICAMP) [The ArchC Architecture Description Language, 2003].

ArchC e baseada em SystemC [SystemC Homepage, 2003] e esta foi a principalrazao de sua escolha noambito deste projeto.

Uma descricao ArchC e composta de duas partes principais. A primeirae adescricao do conjunto de instrucoes da arquitetura (ACISA), onde o projetista dispo-nibiliza todos os detalhes sobre o conjunto de instrucoes, tais como: nome das instrucoes,formatos, tamanhos e outras informacoes necessarias para decodifica-las. A segunda partee a descricao dos elementos da arquitetura (ACARCH), onde o projetista descreve a listade recursos da arquitetura, tais como modulos de armazenamento, estrutura do pipeline,etc.

A partir destas duas descricoes, o pre processador ArchC (acpp) gera o esqueletodo simulador da arquitetura, que contem as assinaturas dos metodos que especificam ocomportamento de cada instrucao, o comportamento comum a cada formato de instrucaoe o comportamento comum a todas as instrucoes [Rigo, 2004].

ArchC e uma linguagem adequada tanto para a modelagem puramente funcionalquanto para a modelagem funcional com precisao de ciclos.

3.2. Modelagem puramente funcional

O modelo puramente funcional do PIC 16F84e composto de 3 arquivos basicos. O pri-meiro contem a descricao da arquitetura (pic16F84.ac). Parte desta descricao pode servisualizada na figura 1, onde estao declarados respectivamente, 5 MB de memoria, umbanco com 256 registradores, a palavra de dados de 8 bits e um registrador chamado W (oacumulador). No construtor (ARCHCTOR), sao declarados o arquivo com a descricaoda arquitetura do conjunto de instrucoes (pic16F84isa.ac) e oendian.

Figura 1: Descric ao da arquitetura do PIC 16F84

A descricao do arquitetura do conjunto de instrucoes (ISA)e composta de trespartes. A primeira partee a declaracao dos formatos de instrucoes. Sao declarados quatroformatos de instrucao, todos com 16 bits2 ao todo. A segunda secao associa as instrucoesaos seus respectivos formatos. Por exemplo, as instrucoes BCF, BSC, BTFSC e BTFSSsao associadas ao formato bit (declarado comoFormat_Bit ). Na ultima parte, encap-sulada no construtor ISA (ISA_CTOR), cada instrucaoe associada a um mnemonico e oscampos fixos sao definidos atraves da diretivaset_decoder . Por exemplo, a instrucaoMOVWF e associada ao minemonicoMOVWF %f, e os campos opbyte e d sao configu-rados para seus valores fixos, opbyte com o opcode da instrucao e o campo d, que indicase o registrador destinoe o acumulador ou o proprio registrador indicado na instrucao.Como MOVWF sempre movera o valor do acumulador para um registrador destino, ocampo de fixo em 1.

3.3. Modelagem funcional com precisao de ciclos

Al em do comportamento da correlacao entre entradas e saıdas, a modelagem funcionalcom precisao de ciclos, captura os atrasos decorrentes da execucao de cada operacao(timing).

Para construir tal modelo do micro-controlador PIC, foi necessario deduzir a es-trutura de seu pipeline, ja que o manual do fabricante [Microchip, 1998]e bastanteesuperficial nesse aspecto.

3.3.1. Estrutura do modelo

Para construir um modelo de precisao de ciclos,e necessario conhecer a maneira comoArchC gerencia a execucao dos estagios do pipeline. Todas as instrucoes passam portodos os estagios indicados, a menos que sejam eliminadas do pipeline, sendo que a cada

2Foram acrescentados 2 dummy bits a todos os formatos de instrucao devido a uma limitacao da lingua-gem ArchC, que aceita apenas comprimentos de instrucao em multiplos de 8.

ciclo, um estagio de cada instrucaoe executado, partindo doultimo ate chegar ao primeiroestagio.

Para cada instrucao, independentemente do estagio, ocorre o seguinte processo:

1. O comportamento generico (comum a todas as instrucoes)e executado.2. O comportamento do formato da instrucaoe executado.3. O comportamento especifico da instrucaoe executado.

3.4. Hazardsde controle

Na ausencia dehazards, o pipeline opera de modo que uma nova instrucao seja iniciada acada ciclo.

Uma instrucao e buscada, decodificada, executada e seu resultadoe escrito noregistrador destino. E desta forma, enquanto a instrucao estiver ocupando um determinadoestagio, a instrucao seguinte estara ocupando o estagio anterior.

No entanto, as instrucoes de desvio resultam emhazardsde controle. Isto porqueuma instrucao de desvio so e decodificada no estagio ID, e nesse caso a instrucao seguintea instrucao de desvio, que nao necessariamente sera a proxima instrucao a ser executada,ja foi buscada. Os proximos paragrafos descrevem como essa instrucaoe nulificada.

Para as instrucoes de desvio incondicional (CALL, GOTO, RETLW, RETFIE,RETURN), logo que a instrucaoe identificada no estagio ID, a instrucao que atualmenteocupa o estagio IFe descartada.

Para as instrucoes de desvio condicional, quando a condicao de desvio naoe satis-feita, instrucao se comporta como as demais instrucoes. No entanto, quando a condicaofor verificada no estagio EX, a instrucao seguinte deve ser eliminada do pipeline (en-quanto esta no estagio ID).

E importante ressaltar que o PIC nao possui instrucoes de desvio condicional paraum endereco absoluto ou mesmo relativo. Quando a condicao de desvioe satisfeita, oendereco alvoe sempre a segunda instrucao que sucede a instrucao de desvio, sendo ainstrucao sucessora imediatamente anulada.

Mesmo que a instrucao corrente seja um desvio, a proxima instrucaoe buscada nociclo seguinte independentemente do resultado do teste.

3.4.1. Hazardsde dados

Como a leitura e a escrita do acumulador/banco de registradores, estao separadas por 1estagio (a leitura ocorre no estagio ID, enquanto a escrita no estagio WB), foi necessariotratar os hazards que ocorrem quando uma instrucao acessar o valor de um registrador quea instrucao no estagio EX ira atualizar somente no proximo ciclo (estagio WB).

Essa situacao e contornada utilizando a tecnica deforwarding ou bypassing[Patterson and Hennessy, 2000], que neste caso consiste em adiantar o resultado da ULAdo ciclo atual, para um de seus operandos no proximo ciclo, antes mesmo que este valorseja escrito no registrador destino.

4. Resultados ExperimentaisPara validacao dos modelos do PIC foram utilizados 8 dos 9 benchmarks disponıveisna pagina oficial do projeto Dalton [Dalton, 2001]. Estes sao os mesmos bench-marks utilizados para validar o modelo do 8051 construıdo na Universidade Fede-ral de Pernambuco - UFPE, e tambem disponıvel no repositorio da linguagem ArchC

[The ArchC Architecture Description Language, 2003]. Ounico benchmark nao utili-zado foi oxrampor nao ser aplicavel ao PIC cuja memoria e bastante limitada.

Os benchmarks foram compilados com o compilador C da CCSR©, e montadoscom um montador gerado automaticamente atraves de uma ferramenta construıda emnosso grupo de pesquisa [Taglietti et al., 2005]. Esses programas exploraram muitas dassituacoes reais de um programa embutido e serao melhor descritos na proxima secao.

4.1. Benchmarkse configuracao experimental

A tabela 1 mostra, para cada programa, o tamanho do codigo (expresso em palavras deinstrucao de 14-bits), e o numero de instrucoes executadas.

Tamanho de Numero de instrucoesC codigo (em palavras) executadas

cast.c 60 68divmul.c 106 296

fib.c 70 358gcd.c 32 125

int2bin. 36 256negcnt.c 30 150

sort.c 110 2227sqroot.c 863 6328

Tabela 1: Dados sobre os benchmarks

O ambiente utilizado para realizar os experimentos foi um AMD Athlon(TM) XP2.4+ GHz, rodando Debian GNU/Linux (versao do Kernel 2.6.8-2-k7), com 512 MB dememoria principal e 256 KB de cache.

4.2. Comparacao com modelo congenere

Com o objetivo de avaliar a eficiencia dos modelos uma bateria de experimentos foi rea-lizada.

Primeiro, foram feitas comparacoes com um modelo congenere, o do micro-controlador 8051, desenvolvido na UFPE.

A figura 2 apresenta uma comparacao entre o numero de instrucoes executadaspara um subconjunto dosbenchmarks. Os benchmarkspara o 8051 foram compiladoscom o Keil’s i8051 compiler.

Note que, devidoa inexistencia de um compilador de domınio publico que gerecodigo para ambos os modelos, dois compiladores comerciais foram utilizados. Portanto,diferentes tecnicas de otimizacao podem ter sido utilizadas, dificultando a comparacaofeita dos resultados.

Percebe-se que, o numero de instrucoes executadas para o PICe sempre inferior.Este comportamentoe provavelmente devidoa dificuldade de otimizar codigo para o 8051ou deficiencia do compilador utilizado.

Como o 8051e uma arquitetura CISC, a superioridade do PIC ja era esperada, poisos compiladores em geral, tem mais facilidade em gerar codigo para arquiteturas RISClike [Patterson and Hennessy, 2000].

Figura 2: Numero de instruc oes executadas

Figura 3: Tempo de simulac ao

4.3. Resultados para o modelo puramente funcional

A figura 3 mostra os tempos de simulacao (em unidades de tempo do SystemC) para osmodelos funcionais do PIC e do 8051.

A diferencae bastante significativa, chegando a varias vezes em alguns casos (caste int2bin por exemplo). Pode-se atribuir essa diferenca principalmente ao processo dedecodificacao das instrucoes, quee bastante complexo para o 8051, devido a variacao notamanho das instrucoes e a multiplicidade de formatos, enquanto o PIC possui tamanhofixo de instrucao e apenas 4 formatos.

4.4. Resultados para o modelo com precisao de ciclos

Com a disponibilidade de um modelo funcional com precisao de ciclos, um outro tipo deanalise pode ser realizado. O impacto do numero de instrucoes eliminadas do pipeline,devido a hazards de controle (ver secao 3.4), ou seja, aquelas instrucoes que sao buscadas,mas, nao chegam a concluir sua execucao (bolhas no pipeline).

Em media, para os benchmarks utilizados, 17,59 % das instrucoes carregadas naocompletam sua execucao. No melhor caso (sort) 10,71 % nao se completam e no pior(negcnt), 30,23 %.

O numero de ciclos perdidos poderia ser reduzido com uma tecnica de previsaode desvios [Patterson and Hennessy, 2003], nao suportada no PIC.

5. Conclusoes e Trabalhos Futuros

Os modelos descritos mostraram-se bastante robustos em face ao numero de experimentosrealizados e ao numero de benchmarks submetidos, alguns bastante complexos como,sqroot, por exemplo.

Atraves das comparacoes com o modelo do 8051, pode-se perceber tambem aeficiencia do modelo do PIC, que se mostrou superior aquele, em termos de tempo desimulacao.

Nao e de conhecimento do autor que modelos similares aos aqui apresentados,estejam disponıveis em repositorio de domınio publico, o que torna os produtos destetrabalho uma contribuicao tecnica efetiva para o projeto baseado no reuso de IPs.

Os modelos ja foram certificados pela equipe ArchC e estao disponıveis em seurepositorio publico [The ArchC Architecture Description Language, 2003]. Isto permiteque os modelos sejam utilizados na exploracao do espaco de projeto que demande ummicrocontrolador, analisando a adequacao em relacao aos requisitos do sistema ou esti-mando desempenho.

Os modelos podem ainda ser utilizados na geracao automatica de ferramentas,como simuladores e montadores que ja estao disponıveis, alem de outras sob desenvolvi-mento.

A disponibilidade de um modelo com precisao de ciclos permite, por exemplo, avalidacao de ferramentas que envolvamtiming, tais como um escalonador de codigo e umdepurador de codigo com precisao de ciclos, alem de fornecer insumos para a ferramentade estimativa de consumo de potencia.

Referencias

Bergamaschi, R. (2002). A to Z of SoCs. InTutorial apresentado na Escola de Microe-letronica da SBC Sul (EMICRO 2002), Florianopolis - Brazil.

Dalton (2001). Synthesizable VHDL model of 8051. http://www.cs.ucr.edu/ dal-ton/i8051/i8051syn/.

Microchip (1998). PIC 16F8X: 18-pin Flash/EEPROM 8 Bit Microcontrollers.

Patterson, D. A. and Hennessy, J. L. (2000).Organizacao e Projeto de Computadores.Campus, 2nd edition.

Patterson, D. A. and Hennessy, J. L. (2003).Arquitetura de Computadores: Uma Abor-dagem Quantitativa. Campus, 3rd edition.

Rigo, S. (2004). ArchC: Uma linguagem de descricao de Arquiteturas. Instituto deComputacao. Universidade Estadual de Campinas - Brasil.

Sangiovanni-Vincentelli, A. and Martin, G. (2001). Platform-based design and soft-ware design methodology for embedded systems.IEEE Design & Test of Computers,18(6):23–33.

SystemC Homepage (2003). SystemC Homepage. http://www.systemc.org.

Taglietti, L., Filho, J. O. C., Casarotto, D., Furtado, O. J. V., and dos Santos, L. C. V.(2005). Automatic ADL-based assembler generation for ASIP programming support.

In The 3rd International IEEE Northeast Workshop on Circuits and Systems, QuebecCity, Canada. http://www.newcas.org.

The ArchC Architecture Description Language (2003). The ArchC Architecture Descrip-tion Language. http://www.archc.org.

modelagem do pic 16f84 para projeto de sistemas …

Documents