Uma plataforma virtual para sistemas embutidos baseado em microcontrolador

Texto

(1)Gabriel Renaldo Laureano. Modelagem do PIC 16F84 para Projeto de Sistemas Embutidos Baseados em Micro-controlador. Florianópolis – SC 2005.

(2) Gabriel Renaldo Laureano. Modelagem do PIC 16F84 para Projeto de Sistemas Embutidos Baseados em Micro-controlador Monografia apresentada ao programa de Bacharelado em Ciências da Computa¸caõ da Universidade Federal de Santa Catarina como requisito parcial para obten¸cão do grau de Bacharel em Ciências da Computa¸cão.. Orientador: Luiz Cl´ audio Villar dos Santos. Universidade Federal de Santa Catarina ´ gico Centro Tecnolo. Florianópolis – SC 2005.

(3) Monografia de gradua¸cão sob o t´ıtulo Modelagem do PIC 16F84 para Projeto de Sistemas Embutidos Baseados em Micro-controlador, defendida por Gabriel Renaldo Laureano e aprovada em 02 de junho de 2005, em Florianópolis, Santa Catarina, pela banca examinadora constitu´ıda pelos professores:. Prof. Dr. Luiz Cláudio Villar dos Santos Orientador Universidade Federal de Santa Catarina. Prof. Dr. Luiz Fernando Friedrich Universidade Federal de Santa Catarina. Prof. Dr. Olinto José Varela Furtado Universidade Federal de Santa Catarina.

(4) “Computer science is no more about computers than astronomy is about telescopes.” Edsger Dijkstra.

(5) Sum´ ario. Lista de Figuras Lista de Tabelas Resumo 1 Introdu¸c˜ ao. p. 7. 2 O Micro-controlador PIC. p. 9. 2.1. Conjunto de instru¸cões do PIC. . . . . . . . . . . . . . . . . . . . . . .. p. 9. 2.2. O Registrador de status . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 10. 2.3. Endere¸camento indireto . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 11. 3 Modelagem Funcional. p. 14. 3.1. A linguagem de descri¸cão de arquiteturas adotada . . . . . . . . . . . .. p. 14. 3.2. Modelagem puramente funcional . . . . . . . . . . . . . . . . . . . . . .. p. 15. 3.3. Modelagem funcional com precisão 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 configura¸cão experimental . . . . . . . . . . . . . . . . .. p. 23. 4.2. Valida¸cão dos modelos . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 24.

(6) 4.2.1. Testes unitários . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 24. 4.2.2. Testes de integra¸cão . . . . . . . . . . . . . . . . . . . . . . . .. p. 24. 4.2.3. Testes de regressão . . . . . . . . . . . . . . . . . . . . . . . . .. p. 25. 4.3. Compara¸cão com modelo congênere . . . . . . . . . . . . . . . . . . . .. p. 25. 4.4. Resultados para o modelo puramente funcional . . . . . . . . . . . . . .. p. 27. 4.5. Resultados para o modelo com precisão de ciclos . . . . . . . . . . . . .. p. 28. 5 Conclus˜ oes e Trabalhos Futuros 5.1. Produtos de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 29 p. 29. Referˆ encias. p. 31. Apˆ endice A -- C´ odigo 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. Apˆ endice B -- Artigo. p. 111.

(7) Lista de Figuras 1. Endere¸camento indireto de instru¸cões . . . . . . . . . . . . . . . . . . .. p. 11. 2. Endere¸camento indireto de dados . . . . . . . . . . . . . . . . . . . . .. p. 12. 3. Descri¸cão da arquitetura do PIC 16F84 . . . . . . . . . . . . . . . . . .. p. 15. 4. Descri¸cão da arquitetura do conjunto de instru¸cões . . . . . . . . . . .. p. 16. 5. Datapath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 17. 6. Comportamento genérico para todas as instru¸cões . . . . . . . . . . . .. p. 19. 7. Comportamento comum a todas as instru¸cões do formato byte . . . . .. p. 20. 8. Comportamento espec´ıfico da instru¸cão 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. N´ umero de instru¸cões executadas . . . . . . . . . . . . . . . . . . . . .. p. 26. 15. Tamanho de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 27. 16. Tempo de simula¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 27. 17. Instru¸cões executadas x buscadas . . . . . . . . . . . . . . . . . . . . .. p. 28.

(8) Lista de Tabelas 1. Conjunto de instru¸cões do PIC. . . . . . . . . . . . . . . . . . . . . . .. p. 13. 2. Descri¸cão dos benchmarks utilizados . . . . . . . . . . . . . . . . . . . .. p. 23. 3. Dados sobre os benchmarks. . . . . . . . . . . . . . . . . . . . . . . . .. p. 24. 4. Impacto de hazards de controle no pipeline . . . . . . . . . . . . . . . .. p. 28.

(9) Resumo Com a abundância de dispositivos dispon´ıveis em um u ńico chip e a demanda imposta por aplica¸cões cada vez mais desafiantes dentro da ind´ ustria de sistemas embarcados, vem aparecendo no mercado, sistemas integrados de software e hardware (CPU, memória e periféricos), os chamados Systems-on-Chip(SoCs). Para reduzir o custo de desenvolvimento e acomodar o time-to-market, o projeto de SoCs tende a adotar uma plataforma-alvo, ou seja, uma arquitetura de referência concebida para viabilizar o reuso de seus componentes, chamados de blocos de propriedade intelectual (IPs). Tal plataforma pode então ser personalizada para uma aplica¸cão espec´ıfica, através da remo¸cão de IPs desnecessários e/ou inclusão de novos IPs. Este trabalho aborda a modelagem eficiente de um IP. O IP modelado é o PIC 16F84, um micro-controlador de uso bastante difundido na ind´ ustria. São apresentados dois modelos: um puramente funcional e outro com precisão de ciclos. Tais modelos estão dispon´ıveis em repositório p´ ublico. Palavras Chave: SoCs, IP, SystemC, ArchC..

(10) 7. 1. Introdu¸ c˜ ao. Os microprocessadores fazem parte de nossas vidas já há algum tempo. No entanto, eles se tornaram poderosos o suficiente para realizar fun¸cões verdadeiramente sofisticadas, somente nos u ´ltimos anos. A evolu¸cão da tecnologia dos circuitos integrados, propulsora desta explosão no poder dos microprocessadores, regida pela lei de Moore1 resulta em milhões de portas lógicas em uma u ńica pastilha de sil´ıcio. Essa enorme oferta de hardware, combinada com a crescente demanda de aplica¸cões na ind´ ustria de sistemas embarcados, resultou no aparecimento de sistemas integrados de hardware (CPU, memória e periféricos) e software sob a forma de Systems-on-Chip (SoCs)[1]. Devido ao crescimento do n´ umero de transistores em progressão geométrica, os projetos de sistemas embarcados se tornam viáveis apenas se utilizadas ferramentas de Projeto Auxiliado por Computador (CAD) e Automa¸cão de Projeto Eletrônico (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 referência concebida para viabilizar o reuso de seus componentes, chamados de blocos de propriedade intelectual (IPs). Tal plataforma pode então ser personalizada para uma aplica¸cão espec´ıfica, através da remo¸cão de IPs desnecessários e/ou inclusão de novos IPs. Embora motivada sobretudo pelas necessidades do projeto de SoCs, a no¸cão de plataforma também norteia o projeto de sistemas implementados em lógica reconfigurável [5, 7]. O processo de personaliza¸cão de uma plataforma requer a explora¸cão de arquiteturas alternativas resultantes da sele¸cão de diferentes conjuntos de IPs. Tal explora¸cão envolve a verifica¸cão do comportamento do sistema em face dos requisitos funcionais, a estimativa de desempenho em face de restri¸cões de tempo real e a estimativa de potência em face da necessidade de baixo consumo de energia. Isso requer a disponibilidade de modelos 1. A Lei de Moore prevê que, a cada 18 meses, dobra o n´ umero de transistores em um circuito integrado (CI)..

(11) 8. eficientes para cada um dos IPs. Este trabalho aborda a modelagem eficiente de um IP, em dois n´ıveis de abstra¸cão diferentes: um puramente funcional e outro com precisão de ciclos. O IP modelado corresponde a um micro-controlador de uso bastante difundido na ind´ ustria, o PIC 16F84. Ambos os modelos foram descritos formalmente, sendo validados através de um conjunto de casos de teste. O trabalho desenvolvido faz parte do projeto DESERT - Desenvolvimento de Software para Sistemas Embutidos sob Restri¸cões de Tempo Real do Laboratório de Automa¸cão 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 Pós Gradua¸caõ em Ciências da Computa¸cão (PPGCC) da UFSC [21]. O segundo modelo foi integralmente desenvolvido pelo autor. O restante deste trabalho está organizado como segue: a arquitetura-alvo escolhida será brevemente descrita na próxima se¸cão (Se¸cão 2); a linguagem de descri¸cão e as estratégias utilizadas na modelagem funcional e com precisão de ciclos, na se¸cão 3. O processo de valida¸cão experimental dos modelos e os resultados obtidos serão relatados na se¸cão 4 e, finalmente, na se¸cão 5 serão apresentadas as conclusões e os trabalhos futuros..

(12) 9. 2. O Micro-controlador PIC. Esta se¸cão descreve sucintamente a arquitetura e a organiza¸cão do micro-controlador PIC, cuja modelagem será abordada nas se¸cões 3 e 3.3. Mais informa¸cões sobre este micro-controlador podem ser obtidas na página oficial do fabricante [9] e no manual de referência [8]. Para detalhes sobre programa¸cão e utiliza¸cão do PIC, as referências [3] e [14] podem ser consultadas. O PIC é um micro-controlador inspirado em arquiteturas RISC que adota máquina de Harvard baseada em acumulador [13], permitindo que as palavras de dados e de instru¸cão possuam tamanhos diferentes, (8 e 14-bits respectivamente). Com exce¸cão das instru¸cões de desvio, que possuem latência1 1, as demais instru¸cões possuem latência 0. O acumulador do PIC é comumente referenciado por W, nota¸cão que será doravante adotada neste texto.. 2.1. Conjunto de instru¸ c˜ oes do PIC. O PIC possui 35 instru¸cões que podem ser separadas em 3 diferentes formatos: • Orientadas a byte: 18 instru¸cões podem ser mapeadas para este formato, elas possuem no máximo dois operandos e operam sobre dados em registradores. • Orientadas a bit: Apenas 4 instru¸cões são mapeadas para este formato, que ´ agrupa instru¸cões para verifica¸cão e altera¸cão de bits em um dado registrador. E neste formato que se encontram algumas instru¸cões de desvio condicional (Bit Test f, Skip if Clear - BTFSC e Bit Test f, Skip if Set - BTFSS ). 1. O autor utiliza o termo latência, neste contexto, para se referir ao n´ umero de ciclos perdidos entre o término da busca de uma intru¸c˜ ao e o ´ınicio da busca da próxima instru¸cão efetiva, como mostra a figura 10..

(13) 10. • Literal: Neste formato se encontram as opera¸cões sobre valores imediatos, que operam o acumulador com um literal contido na própria instru¸cão. Exemplos de instru¸cões deste formato são ADDLW, ANDLW e MOVLW. • Controle: As instru¸cões mapeadas para este formato são responsáveis, dentre outras opera¸cões de controle, pelas opera¸cões de desvio incondicional (GOTO), chamada e retorno de procedimento (CALL, RETURN, RETLW ) e ainda retorno de interrup¸cão (RETFIE ). O conjunto de instru¸cões do PIC está descrito na tabela 1, extra´ıda do manual de referência [8].. 2.2. O Registrador de status. O registrador STATUS é um registrador de uso especial que armazena, em seus 3 bits menos significativos, informa¸cões sobre resultados das u ´ltimas opera¸cões aritméticas. A coluna Status Affected presente na tabela 1 representa os bits do registrador STATUS afetados após a execu¸cão de uma dada instru¸cão, como segue: • Z: Zero bit (bit 2) ´ 1 se o resultado de uma opera¸cão aritmética ou lógica foi zero. Em caso contrário, E é 0. • DC: Digit Carry/borrow bit (bit 1) ´ 1 se ocorreu um “vai um” do terceiro para o quarto bit nas instru¸cões de adi¸cão E e 0 em caso contrário. Nas instru¸cões de subtra¸cão, este bit será 0 se ocorreu um “vem um”, do terceiro para o quarto bit e 1 em caso contrário. • C: Carry/borrow bit (bit 0) ´ 1 se ocorreu um carry-out no sétimo bit durante uma instru¸cão de adi¸cão e 0 em E caso contrário. Nas instru¸cões de subtra¸cão, este bit será 0 se ocorreu um “vem um” no bit mais significativo e 1 em caso contrário. Nas instru¸cões de rota¸cão, ele será carregado com o bit mais ou menos significativo do registrador operado, para rota¸cão à direita e esquerda (RRF e RLF ) respectivamente. Os bits C e Z em conjunto com as opera¸cões de subtra¸cão e de verifica¸cão de bits, são suficientes para executar qualquer opera¸cão de compara¸cão (=, ! =, <, <=, >, >=),.

(14) 11. uma vez que um “vem um” em uma opera¸cão de subtra¸cão só ocorrerá quando o primeiro operando for menor que o segundo. Assim o efeito dessas opera¸cões, é equivalente por exemplo, ao das opera¸cões slt, beq, bne do MIPS [12].. 2.3. Endere¸camento indireto. O PIC não possui uma instru¸cão de desvio indireto, como a instru¸cão jr do MIPS. No entanto, possui uma outra caracter´ıstica denominada endere¸camento indireto. O endere¸camento indireto no PIC se baseia em três registradores de uso especifico, que são: • INDF: O registrador INDF não é um registrador f´ısico, uma leitura no registrador INDF retornará o valor contido no registrador cujo endere¸co está armazenado no registrador FSR. • FSR: O registrador FSR é um ponteiro que recebe o endere¸co do registrador que sofrerá as leituras e escritas executadas no registrador INDF. • PCL: O registrador PCL mantém os 8 bits menos significativos do PC. Ao contrário do PCLATH que mantém os 5 bits mais significativos do PC (que é composto de 13 bits), PCL é um registrador de leitura e escrita. A figura 1 apresenta um exemplo de endere¸camento indireto de instru¸cões, onde a primeira instru¸cão (linha 1) efetua uma adi¸cão de um valor pré-carregado em W, com o valor presente em FSR, armazenando o resultado no próprio FSR. Move o valor do registrador indicado por FSR para o acumulador na segunda instru¸cão (linha 2) representando o carregamento de um valor de uma tabela de endere¸cos (onde FSR é o endere¸co da tabela e W o ´ındice) e a u ´ltima instru¸cão (linha 3) representa a escrita deste valor no PC, fazendo o fluxo do programa desviar para o endere¸co indicado, um case de um bloco switch por exemplo (tendo o mesmo efeito da instru¸cão jr do MIPS).. Figura 1: Endere¸camento indireto de instru¸cões.

(15) 12. A figura 2 apresenta um exemplo de endere¸camento indireto de dados, onde as duas primeiras instru¸cões são idênticas ao exemplo anterior, porém representam uma opera¸cão de aritmética de ponteiros (FSR é 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: Endere¸camento indireto de dados. Estes registradores são utilizados para a execu¸cão dos ponteiros das linguagens de alto n´ıvel, bem como blocos switch e o polimorfismo das linguagens orientadas a objeto. Isto porque é permitido escrever no byte menos significativo do contador de programa (PCL), e assim o endere¸camento indireto pode ser usado tanto para dados quanto para instru¸cões..

(16) 13. Mnemonic Operands ADDWF f,d ANDWF f,d CLRF f CLRW COMF f,d DECF f,d DECFSZ f,d INCF f,d INCFSZ f,d IORWF f,d MOVF f,d MOVWF f NOP RLF f,d RRF f,d SUBWF f,d SWAPF f,d XORWF f,d BCF f,b BSF f,b BTFSC f,b BTFSS f,b ADDWF f,d ANDWF f,d CLRF f CLRW COMF f,d DECF f,d DECFSZ f,d INCF f,d INCFSZ f,d IORWF f,d MOVF f,d MOVWF f NOP RLF f,d RRF f,d SUBWF f,d SWAPF f,d XORWF f,d. Description. Cycles. 14-Bit Opcode MSb LSb BYTE-ORIENTED FILE REGISTER OPERATIONS Add W and f 1 00 0111 dfff ffff AND W with f 1 00 0101 dfff ffff Clear f 1 00 0001 1fff ffff Clear W 1 00 0001 0xxx xxxx Complement f 1 00 1001 dfff ffff Decrement f 1 00 0011 dfff ffff Decrement f, Skip if 0 1(2) 00 1011 dfff ffff Increment f 1 00 1010 dfff ffff Increment f, Skip if 0 1(2) 00 1111 dfff ffff Inclusive OR W with f 1 00 0100 dfff ffff Move f 1 00 1000 dfff ffff Move W to f 1 00 0000 1fff ffff No Operation 1 00 0000 0xx0 0000 Rotate Left f through Carry 1 00 1101 dfff ffff Rotate Right f through Carry 1 00 1100 dfff ffff Subtract W from f 1 00 0010 dfff ffff Swap nibbles in f 1 00 1110 dfff ffff Exclusive OR W with f 1 00 0110 dfff ffff BIT-ORIENTED FILE REGISTER OPERATIONS Bit Clear f 1 01 00bb bfff ffff Bit Set f 1 01 01bb bfff ffff Bit Test f, Skip if Clear 1(2) 01 10bb bfff ffff Bit Test f, Skip if Set 1(2) 01 11bb bfff ffff LITERAL AND CONTROL OPERATIONS Add W and f 1 00 0111 dfff ffff AND W with f 1 00 0101 dfff ffff Clear f 1 00 0001 1fff ffff Clear W 1 00 0001 0xxx xxxx Complement f 1 00 1001 dfff ffff Decrement f 1 00 0011 dfff ffff Decrement f, Skip if 0 1(2) 00 1011 dfff ffff Increment f 1 00 1010 dfff ffff Increment f, Skip if 0 1(2) 00 1111 dfff ffff Inclusive OR W with f 1 00 0100 dfff ffff Move f 1 00 1000 dfff ffff Move W to f 1 00 0000 1fff ffff No Operation 1 00 0000 0xx0 0000 Rotate Left f through Carry 1 00 1101 dfff ffff Rotate Right f through Carry 1 00 1100 dfff ffff Subtract W from f 1 00 0010 dfff ffff Swap nibbles in f 1 00 1110 dfff ffff Exclusive OR W with f 1 00 0110 dfff ffff Tabela 1: Conjunto de instru¸cões do PIC. Status Affected C,DC,Z Z Z Z Z Z Z Z Z. C C C,DC,Z Z. C,DC,Z Z Z Z Z Z Z Z Z. C C C,DC,Z Z.

(17) 14. 3. Modelagem Funcional. A modelagem funcional de um sistema não considera como este sistema será implementado. Somente o comportamento da correla¸cão entre entradas e sa´ıdas é relevante neste n´ıvel de abstra¸cão. Para descrever o micro-controlador PIC, foi utilizada uma linguagem de descri¸cão de arquitetura (ADL), que será brevemente introduzida na se¸cão seguinte.. 3.1. A linguagem de descri¸ c˜ ao de arquiteturas adotada. ArchC é uma linguagem de descri¸cão de arquitetura que foi desenvolvida no Laboratório de Sistemas Computacionais (LSC) do Instituto de Computa¸cão da Universidade de Campinas (IC/UNICAMP) [23]. ArchC é baseada em SystemC [19, 11] e esta foi a principal razão de sua escolha no âmbito deste projeto. Uma descri¸cão ArchC é composta de duas partes principais. A primeira é a descri¸cão do conjunto de instru¸cões da arquitetura (AC ISA), onde o projetista disponibiliza todos os detalhes sobre o conjunto de instru¸cões, tais como: nome das instru¸cões, formatos, tamanhos e outras informa¸cões necessárias para decodificá-las. A segunda parte é a descri¸cão dos elementos da arquitetura (AC ARCH), onde o projetista descreve a lista de recursos da arquitetura, tais como módulos de armazenamento, estrutura do pipeline, etc. A partir destas duas descri¸cões, o pré processador ArchC (acpp) gera o esqueleto do simulador da arquitetura, que contém as assinaturas dos métodos que especificam o comportamento de cada instru¸cão, o comportamento comum a cada formato de instru¸cão e o comportamento comum a todas as instru¸cões [23, 17]..

(18) 15. ArchC é uma linguagem adequada tanto para a modelagem puramente funcional quanto para a modelagem funcional com precisão de ciclos.. 3.2. Modelagem puramente funcional. O modelo puramente funcional do PIC 16F84 é composto de 3 arquivos básicos. O primeiro contém a descri¸cão da arquitetura (pic16F84.ac). Parte desta descri¸cão pode ser visualizada na figura 3, onde estão declarados respectivamente, 5 MB de memória, um banco com 256 registradores, a palavra de dados de 8 bits e um registrador chamado W (o acumulador). No construtor (ARCH CTOR), são declarados o arquivo com a descri¸cão da arquitetura do conjunto de instru¸cões (pic16F84 isa.ac) e o endian.. Figura 3: Descri¸cão da arquitetura do PIC 16F84. A descri¸cão do arquitetura do conjunto de instru¸cões (ISA) é composta de três partes, como mostra a figura 4, que contém apenas um trecho do modelo completo. A primeira parte é a declara¸cão dos formatos de instru¸cões. São declarados quatro formatos de instru¸cão, todos com 16 bits1 ao todo. A segunda se¸cão associa as instru¸cões aos seus respectivos formatos. Por exemplo, as instru¸cões BCF, BSC, BTFSC e BTFSS são associadas ao formato bit (declarado como Format_Bit). Na u ´ltima parte, encapsulada no construtor ISA (ISA_CTOR), cada instru¸cão é associada a um mnemônico e os campos fixos são definidos através da diretiva set_decoder. Por exemplo, a instru¸cão MOVWF é associada ao minemônico MOVWF %f, e os campos opbyte e d são configurados para seus valores fixos, opbyte com o opcode da instru¸cão e o campo d, que indica se o registrador destino é o acumulador ou o próprio registrador indicado na instru¸cão. Como MOVWF sempre moverá o valor do acumulador para um registrador destino, o campo d é fixo em 1. 1. Foram acrescentados 2 dummy bits a todos os formatos de instru¸cão devido a uma limita¸cão da linguagem ArchC, que aceita apenas comprimentos de instru¸cão em multiplos de 8..

(19) 16. Figura 4: Descri¸cão da arquitetura do conjunto de instru¸cões. 3.3. Modelagem funcional com precis˜ ao de ciclos. Além do comportamento da correla¸cão entre entradas e sa´ıdas, a modelagem funcional com precisão de ciclos, captura os atrasos decorrentes da execu¸cão de cada opera¸cão (timing). Para construir tal modelo do micro-controlador PIC, foi necessário deduzir a estrutura de seu pipeline, já que o manual do fabricante [8] é bastante é superficial nesse aspecto. Foi necessário usar elementos da linguagem ArchC não utilizados na descri¸cão do modelo funcional, como segue: ac pipe - Constrói um pipeline com tantos estágios quantos forem nominados. Por exemplo, no modelo desenvolvido, a declara¸cão: ac_pipe pipe = {IF, ID, EX, WB};, resulta em um pipeline com 4 estágios, que serão associados com as etapas de busca (IF), decodifica¸cão (ID), execu¸cão (EX) e escrita no destino (WB). ac format - Cria um formato que pode ser associado a um registrador. Possue sintaxe.

(20) 17. semelhante à da diretiva de mesmo nome utilizada na descri¸cão do conjunto de instru¸cões, para definir um formato de instru¸cão. Essa diretiva foi utilizada para distinguir os vários campos dos registradores do pipeline.. 3.3.1. Datapath. Na figura 5 podemos observar uma versão 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 estágio. Como podemos observar, no primeiro estágio (IF) acontece a busca da instru¸cão; no segundo estágio (ID), ocorrem paralelamente a decodifica¸cão da instru¸cão e a leitura do banco de registradores e do acumulador (ambas especulativas). Ainda nesse estágio, após a decodifica¸cão, ocorre a sele¸cão do operando A da Unidade Lógica e Aritmética (ULA), bem como a escrita no contador de programa (PC) para as instru¸cões de desvio incondicional, no estágio seguinte (EX) ocorre a sele¸cão do operando B bem como a opera¸cão na ULA, e no u ´ltimo estágio (WB) ocorre a escrita no banco de registradores e no acumulador.. Figura 5: Datapath.

(21) 18. 3.3.2. Estrutura do modelo. Para construir um modelo de precisão de ciclos, é necessário conhecer a maneira como ArchC gerencia a execu¸cão dos estágios do pipeline. Todas as instru¸cões passam por todos os estágios indicados, a menos que sejam eliminadas do pipeline, sendo que a cada ciclo, um estágio de cada instru¸cão é executado, partindo do u ´ltimo até chegar ao primeiro estágio. Para cada instru¸cão, independentemente do estágio, ocorre o seguinte processo: 1. O comportamento genérico (comum a todas as instru¸cões) é executado. 2. O comportamento do formato da instru¸cão é executado. 3. O comportamento especifico da instru¸cão é executado. As figuras 6, 7 e 8 são exemplos de cada um dos comportamentos descritos acima, conforme explicado a seguir. A figura 6 define o comportamento comum a todas as instru¸cões. Como pode ser observado, a variável stage armazena o estágio corrente, permite fazer tratamentos diferenciados para cada estágio do pipeline (essa mesma variável é utilizada nos demais comportamentos). No estágio IF ocorre o incremento do PC, sendo que a busca da instru¸cão (que ocorre no mesmo estágio) fica a cargo do simulador ArchC. No estágio ID, ocorre a leitura do acumulador (que é o segundo operando da ULA por padrão), e todos os sinais de escrita são desabilitados. No estágio EX, ocorre apenas a cópia dos valores comuns aos registradores do pipeline ID EX e EX WB. E no estágio EX ocorre a escrita no registrador alvo e nos bits espec´ıficos do registrador de STATUS (somente quando a escrita estiver habilitada). Não ocorrem acessos de leitura e escrita na memória, devido a sua inexistência no PIC 16F84 que utiliza o espa¸co de endere¸camento apenas para mapear os seus 68 registradores de uso geral. Na figura 7, o comportamento das instru¸cões do formato byte, que tem o registrador destino indicado no campo d e o registrador especificado no campo f são armazenados para uso posterior, bem como o primeiro operando da ULA que é configurado com o valor do mesmo registrador. Na figura 8, o comportamento espec´ıfico da instru¸cão DECFSZ que habilita a escrita no estágio ID. No estágio EX, decrementa-se o valor do registrador de um e verifica-se se.

(22) 19. Figura 6: Comportamento genérico para todas as instru¸cões. o resultado é igual a zero. Se o resultado for nulo, elimina-se do pipeline a instru¸cão que atualmente ocupa o estágio ID.. 3.3.3. Hazards de controle. Na ausência de hazards, o pipeline opera de modo que uma nova instru¸cão seja iniciada a cada ciclo, como ilustra a figura 9: Uma instru¸cão é buscada, decodificada, executada e seu resultado é escrito no registrador destino. E desta forma, enquanto a instru¸cão estiver ocupando um determinado estágio, a instru¸cão seguinte estará ocupando o estágio anterior. No entanto, as instru¸cões de desvio resultam em hazards de controle. Isto porque uma instru¸cão de desvio só é decodificada no estágio ID, e nesse caso a instru¸cão seguinte à instru¸cão de desvio, que não necessariamente será a próxima instru¸cão a ser executada, já foi buscada. Os próximos parágrafos descrevem como essa instru¸cão é nulificada..

(23) 20. Figura 7: Comportamento comum a todas as instru¸cões do formato byte. Figura 8: Comportamento espec´ıfico da instru¸cão DECFSZ. Para as instru¸cões de desvio incondicional (CALL, GOTO, RETLW, RETFIE, RETURN), logo que a instru¸cão é identificada no estágio ID, a instru¸cão que atualmente ocupa o estágio IF é descartada, como ilustra a figura 10. Para as instru¸cões de desvio condicional, quando a condi¸cão de desvio não é satisfeita, instru¸cão se comporta como as demais instru¸cões. No entanto, quando a condi¸caõ for verificada no estágio EX, a instru¸cão seguinte deve ser eliminada do pipeline (enquanto está no estágio ID), como o exemplo da figura 11. ´ importante ressaltar que o PIC não possui instru¸cões de desvio condicional para E um endere¸co absoluto ou mesmo relativo. Quando a condi¸cão de desvio é satisfeita, o endere¸co alvo é sempre a segunda instru¸cão que sucede a instru¸cão de desvio, sendo a instru¸cão sucessora imediatamente anulada. Mesmo que a instru¸cão corrente seja um desvio, a próxima instru¸cão é buscada no.

(24) 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, estão separadas por 1 estágio (a leitura ocorre no estágio ID, enquanto a escrita no estágio WB), foi necessário tratar os hazards que ocorrem quando uma instru¸cão acessar o valor de um registrador que a instru¸cão no estágio EX irá atualizar somente no próximo ciclo (estágio WB). Essa situa¸cão é contornada utilizando a técnica de forwarding ou bypassing [12], que.

(25) 22. neste caso consiste em adiantar o resultado da ULA do ciclo atual, para um de seus operandos no próximo ciclo, antes mesmo que este valor seja escrito no registrador destino. O forwarding do valor a ser escrito no acumulador foi tratado no comportamento comum a todas as instru¸cões, como pode ser visto na figura 12. Quando para uma instru¸cão no estágio WB a escrita estiver habilitada e o registrador destino for o acumulador, o valor do operando op B é obtido diretamente da sa´ıda da ULA. Em caso contrário, o valor default de op B é 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 é tratado no comportamento dos formatos byte e bit (Format_Byte e Format_Bit). Quando, para instru¸cão no estágio WB, a escrita estiver habilitada, e o registrador for o mesmo da instru¸cão no estágio EX, o valor será obtido diretamente da sa´ıda da ULA. Em caso contrário o valor default de op A é lido do banco de registradores.. Figura 13: Forwarding do banco de registradores.

(26) 23. 4. Resultados Experimentais. Para valida¸cão dos modelos do PIC foram utilizados 8 dos 9 benchmarks dispon´ıveis na página oficial do projeto Dalton [2]. Estes são os mesmos benchmarks utilizados para validar o modelo do 8051 constru´ıdo na Universidade Federal de Pernambuco - UFPE, e também dispon´ıvel em [23]. O u ńico benchmark não utilizado foi o xram por não ser aplicável ao PIC cuja memória é bastante limitada. r e montados com Os benchmarks foram compilados com o compilador C da CCS , um montador gerado automaticamente através de uma ferramenta constru´ıda em nosso grupo de pesquisa [20]. Esses programas exploraram muitas das situa¸cões reais de um programa embutido e serão melhor descritos na próxima se¸cão.. 4.1. Benchmarks e configura¸ c˜ ao experimental. A tabela 2 apresenta uma breve descri¸cão de cada um dos 8 benchmarks utilizados. cast. Obtêm cada byte que compõe uma constante do tipo long (4 bytes), utilizando coersão para byte (unsigned char) e deslocamentos. divmul Emula opera¸cões de multiplica¸cão, divisão e modulo sobre bytes. fib Obtêm os dez primeiros n´ umeros da série de Fibonaci [4]. gcd Obtêm o maior divisor comum entre 47 e 11 utilizando-se do algoritmo de Euclides[10]. int2bin Obtêm os bits que compõe um n´ umero inteiro, utilizando principalmente deslocamentos e operadores bit-a-bit. negcnt Utiliza coersão 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 compara¸cões. sqroot Extrai a raiz quadrada de 25, utilizando emula¸cão de ponto flutuante e opera¸cões sobre os n´ umeros de ponto flutuante emulados. Tabela 2: Descri¸cão dos benchmarks utilizados.

(27) 24. A tabela 3 mostra, para cada programa, o tamanho do código (expresso em palavras de instru¸cão de 14-bits), e o n´ umero de instru¸cões executadas. Tamanho de N´ umero de instru¸cões C código (em palavras) executadas cast.c 60 68 divmul.c 106 296 fib.c 70 358 gcd.c 32 125 int2bin. 36 256 negcnt.c 30 150 sort.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 (versão do Kernel 2.6.8-2-k7), com 512 MB de memória principal e 256 KB de cache.. 4.2. Valida¸c˜ ao dos modelos. O processo de valida¸cão dos modelos consistiu de três etapas distintas, os testes unitários, os de integra¸cão e os de regressão [16].. 4.2.1. Testes unit´ arios. Os testes unitários consistem em testar cada unidade do sistema separadamente, neste caso, cada instru¸cão. Nesta etapa de valida¸cão dos modelos, efetuamos pelo menos um teste para cada instru¸cão, onde um pequeno programa assembly que utiliza a instru¸cão foi constru´ıdo e executado. As sa´ıdas foram analisadas e comparadas com os resultados esperados. Ao final do processo, todas as instru¸cões de ambos os modelos passaram nos testes unitários.. 4.2.2. Testes de integra¸ c˜ ao. Os testes de integra¸cão objetivam testar o funcionamento das unidades do sistema em conjunto, procurando descobrir defeitos na interface entre os módulos..

(28) 25. Utilizando o conjunto de benchmarks apresentados anteriormente, cujas sa´ıdas esperadas são conhecidas (estão dispon´ıveis na página do projeto Dalton [2]). as seguintes etapas foram realizadas: 1. Para cada benchmark, analisou-se o código gerado pelo compilador, descobrindo a qual registrador o valor de sa´ıda é associado, verificou-se também se esse mesmo registrador não é utilizado em outras partes do código. 2. Gerou-se o simulador, e carregou-se cada um dos benchmarks. Analisou-se as sa´ıdas e verificou-se se corresponderam exatamente às sa´ıdas esperadas. Ambos os modelos tiveram sa´ıdas equivalentes às esperadas para todos os benchmarks. Deve-se resalvar que apenas as instru¸cões ANDLW, CLRW, CLRWDT, INCFSZ, IORWF, RETFIE, RETURN e SWAPF não foram cobertas nos testes de integra¸cão, pois não estão presentes em nenhum dos 8 benchmarks utilizados durante os testes de integra¸cão.. 4.2.3. Testes de regress˜ ao. Em qualquer sistema computacional, a adi¸cão de novas funcionalidades é bastante comum. Um teste de regressão é a re-execu¸cão de um subconjunto de testes, já aplicados em momento anterior, para verificar que após um novo modulo ser adicionado, ou uma corre¸cão ser efetuada, o sistema continua em correto funcionamento. Para que o teste de regressão pudesse ser automaticamente aplicado, todos os testes de integra¸cão, após validados, tiverem suas sa´ıdas salvas. Posteriormente, sempre que necessário, quando o teste for invocado os testes de integra¸cão serão re-executados, e suas sa´ıdas comparadas com as anteriormente salvas (já validadas), ignorando informa¸cões mutáveis (tempo de simula¸cão por exemplo). Em caso de falha, o teste informa quais benchmarks falharam. O teste de regressão foi disponibilizado ao grupo de suporto do Projeto ArchC, e será aplicado a ambos os modelos, sempre que uma nova versão das ferramentas for gerada.. 4.3. Compara¸c˜ ao com modelo congˆ enere. Com o objetivo de avaliar a eficiência dos modelos uma bateria de experimentos foi realizada..

(29) 26. Primeiro, foram feitas compara¸cões com um modelo congênere, o do micro-controlador 8051, desenvolvido na UFPE. A figura 14 apresenta uma compara¸cão entre o n´ umero de instru¸cões executadas para um subconjunto dos benchmarks. Os benchmarks para o 8051 foram compilados com o Keil’s i8051 compiler. Note que, devido à inexistência de um compilador de dom´ınio p´ ublico que gere código para ambos os modelos, dois compiladores comerciais foram utilizados. Portanto, diferentes técnicas de otimiza¸cão podem ter sido utilizadas, dificultando a compara¸cão feita dos resultados.. Figura 14: N´ umero de instru¸cões executadas. Percebe-se que, o n´ umero de instru¸cões executadas para o PIC é sempre inferior. Este comportamento é provavelmente devido à dificuldade de otimizar código para o 8051 ou deficiência do compilador utilizado. Como o 8051 é uma arquitetura CISC, a superioridade do PIC já era esperada, pois os compiladores em geral, tem mais facilidade em gerar código para arquiteturas RISC like [12]. A figura 15 apresenta-se uma compara¸cão em termos de tamanho de código (expresso em bytes). Para 4 benchmarks o código gerado para o PIC é ligeiramente maior do que o do 8051. Este comportamento é esperado uma vez que o PIC usa tamanho fixo para suas instru¸cões. Em dois benchmarks (fib e sort) o código gerado para o PIC é 2 a 2,5 vezes mais compacto..

(30) 27. Figura 15: Tamanho de código. 4.4. Resultados para o modelo puramente funcional. A figura 16 mostra os tempos de simula¸cão (em unidades de tempo do SystemC) para os modelos funcionais do PIC e do 8051.. Figura 16: Tempo de simula¸cão. A diferen¸ca é bastante significativa, chegando a várias vezes em alguns casos (cast e int2bin por exemplo). Pode-se atribuir essa diferen¸ca principalmente ao processo de decodifica¸cão das instru¸cões, que é bastante complexo para o 8051, devido a varia¸cão no tamanho das instru¸cões e a multiplicidade de formatos, enquanto o PIC possui tamanho fixo de instru¸cão e apenas 4 formatos..

(31) 28. 4.5. Resultados para o modelo com precis˜ ao de ciclos. Com a disponibilidade de um modelo funcional com precisão de ciclos, um outro tipo de análise pode ser realizado. O impacto do n´ umero de instru¸cões eliminadas do pipeline, devido a hazards de controle (ver se¸cão 3.3.3), ou seja, aquelas instru¸cões que são buscadas, mas, não chegam a concluir sua execu¸cão (bolhas no pipeline). Na figura 17 e na tabela 4, podemos observar esses dados.. Figura 17: Instru¸cões executadas x buscadas. Benchmarks cast.c divmul.c fib.c gcd.c int2bin. negcnt.c sort.c sqroot.c. N´ umero de Instru¸cões Executadas Carregadas 68 77 296 363 358 401 125 159 256 322 150 215 2227 2494 6328 7625. Ciclos Perdidos (%) 11,69% 18,46% 10,72% 21,38% 20,50% 30,23% 10,71% 17,01%. Tabela 4: Impacto de hazards de controle no pipeline Em média, para os benchmarks utilizados, 17,59 % das instru¸cões carregadas não completam sua execu¸cão. No melhor caso 10,71 % não se completam e no pior, 30,23 %. O n´ umero de ciclos perdidos poderia ser reduzido com uma técnica de previsão de desvios [13], não suportada no PIC..

(32) 29. 5. Conclus˜ oes e Trabalhos Futuros. Os modelos descritos mostraram-se bastante robustos em face ao n´ umero de experimentos realizados e ao n´ umero de benchmarks submetidos, alguns bastante complexos como, sqroot, por exemplo. Através das compara¸cões com o modelo do 8051, pode-se perceber também a eficiência do modelo do PIC, que se mostrou superior aquele, em termos de tempo de simula¸cão. Não é de conhecimento do autor que modelos similares aos aqui apresentados, estejam dispon´ıveis em repositório de dom´ınio p´ ublico, o que torna os produtos deste trabalho uma contribui¸cão técnica efetiva para o projeto baseado no reuso de IPs. Os modelos já foram certificados pela equipe ArchC e estão dispon´ıveis em seu repositório p´ ublico [23]. Isto permite que os modelos sejam utilizados na explora¸cão do espa¸co de projeto que demande um microcontrolador, analisando a adequa¸cão em rela¸cão aos requisitos do sistema ou estimando desempenho. Os modelos podem ainda ser utilizados na gera¸cão automática de ferramentas, como simuladores e montadores que já estão dispon´ıveis, além de outras sob desenvolvimento. A disponibilidade de um modelo com precisão de ciclos permite, por exemplo, a valida¸cão de ferramentas que envolvam timing, tais como um escalonador de código e um depurador de código com precisão de ciclos, além de fornecer insumos para a ferramenta de estimativa de consumo de potência.. 5.1. Produtos de trabalho. Os resultados obtidos com este trabalho foram: • Modelos puramente funcional do PIC 16F84 certificado e dispon´ıvel em repositório p´ ublico[23]..

(33) 30. • Modelo funcional com precis˜ ao de ciclos do PIC 16F84 também certificado e dispon´ıvel em repositório p´ ublico[23]. • Artigo em co-autoria, publicado nos anais do XI Workshop IBERCHIP [22]. • Artigo submetido ao Student Forum on Microelectronics 2005 [6]..

(34) 31. Referˆ encias [1] Reinaldo Bergamaschi. A to Z of SoCs. In Tutorial apresentado na Escola de Microeletrônica da SBC Sul (EMICRO 2002), Florianópolis - Brazil, 2002. [2] Dalton. Synthesizable VHDL model of 8051, 2001. http://www.cs.ucr.edu/ dalton/i8051/i8051syn/. ´ [3] David José de Souza. Desbravando o PIC. Erica, São 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 by Design. Winning the SoC revolution: experiences in real design, chapter 8. Kluwer Academic Publishers, 2003. [6] Gabriel Renaldo Laureano, Leonardo Taglietti, and Luiz Cláudio Villar dos Santos. Functional and cycle-accurate models for the PIC 16F84 micro-controller. Florianópolis, 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. Introdu¸cão à Te´ oria dos N´ umeros. Departamento de Matemática Universidade de Aveiro, 2001. [11] OSCI. SystemC Version 2.0 User’s Guide, 2003. [12] David A. Patterson and John L. Hennessy. Organiza¸c˜ ao e Projeto de Computadores. Campus, 2nd edition, 2000. [13] David A. Patterson and John L. Hennessy. Arquitetura de Computadores: Uma Abordagem Quantitativa. Campus, 3rd edition, 2003. ´ [14] Fábio Pereira. Microcontroladores PIC: Programa¸c˜ ao em C. Erica, 2003. [15] Bruno R. Preiss. Data Structures and Algorithms with ObjectOriented 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..

(35) 32. [17] Sandro Rigo. ArchC: Uma linguagem de descri¸c˜ ao de Arquiteturas. Instituto de Computa¸cão. Universidade Estadual de Campinas - Brasil, Julho 2004. [18] A. Sangiovanni-Vincentelli and G. Martin. Platform-based design and software design methodology 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, José Otávio Carlomagno Filho, Daniel Casarotto, Olinto José Varella Furtado, and Luiz Cláudio Villar dos Santos. Automatic ADL-based assembler generation for ASIP programming support. In The 3rd International IEEE Northeast Workshop on Circuits and Systems, Québec City, Canada, June 19-22 2005. http://www.newcas.org. [21] Leonardo Taglietti, Olinto José Varela Furtado, and Luiz Cláudio Villar dos Santos. Gera¸cão automática de ferramentas de suporte ao desenvolvimento de software embarcado para ASIPs. Master’s thesis, Programa de Pós-gradua¸cão em Ciências da Computa¸cão - UFSC - Brasil, Florianópolis-SC, Fevereiro 2005. [22] Leonardo Taglietti, Gabriel Renaldo Laureano, Carlos Rodrigo Toffoli Fernandes, and Luiz Cláudio Villar dos Santos. Modelagem do microcontrolador PIC 16F84 para projeto baseado no reuso de IPs. In Anais do XI Workshop IBERCHIP, pages 251–252, Salvador - Bah´ıa, Brasil, 28-30 de Mar¸co 2005. http://www.iberchip.org/iws2005. [23] The ArchC Architecture Description Language, 2003. http://www.archc.org..

(36) 33. ˆ APENDICE A -- C´ odigo Fonte dos Modelos.

(37) 34. A.1. constants.h. 1. /*******************************************************. 2. * The ArchC PIC 16F84 functional model.. *. 3. *. *. 4. * Author:. *. 5. * Gabriel Renaldo Laureano - laureano@inf.ufsc.br. *. 6. * Leonardo Taglietti. *. 7. *. *. 8. * For more information on ArchC, please visit:. *. 9. * http://www.archc.org. *. 10. - leonardo@inf.ufsc.br. *******************************************************/. 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.

(38) 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.

(39) 36. 64 #define CLEAR 0 65 #endif /* CONSTANTS_H */.

(40) 37. A.2. pic16F84.ac. 1 /******************************************************** 2. * The ArchC PIC 16F84 functional model.. *. 3. *. *. 4. * Author:. *. 5. * Gabriel Renaldo Laureano - laureano@inf.ufsc.br. *. 6. * Leonardo Taglietti. *. 7. *. *. 8. * For more information on ArchC, please visit:. *. 9. * http://www.archc.org. *. 10. - leonardo@inf.ufsc.br. *******************************************************/. 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. }; };.

(41) 38. A.3. pic16F84 isa.ac. 1. /*******************************************************. 2. * The ArchC PIC 16F84 functional model.. *. 3. *. *. 4. * Author:. *. 5. * Gabriel Renaldo Laureano - laureano@inf.ufsc.br. *. 6. * Leonardo Taglietti. *. 7. *. *. 8. * For more information on ArchC, please visit:. *. 9. * http://www.archc.org. *. 10. - leonardo@inf.ufsc.br. *******************************************************/ /*. 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,.

(42) 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);.

(43) 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);.

(44) 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);.

(45) 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);. 108. //colocada no formato Byte. 109. RETFIE.set_asm("RETFIE");. 110. RETFIE.set_decoder(opbyte=0x0, d=0, f=0x09);. 111. //colocada no formato Byte. 112. RETURN.set_asm("RETURN");. 113. RETURN.set_decoder(opbyte=0x00, d=0, f=0x08);. 114. //colocada no formato Byte. 115. SLEEP.set_asm("SLEEP");. 116. SLEEP.set_decoder(opbyte=0x0, d=0, f=0x63);. 117. //----------------------------------------------------------------. 118 119 };. };.

(46) 43. A.4. pic16F84-isa.cpp. 1. /*******************************************************. 2. * The ArchC PIC 16F84 functional model.. *. 3. *. *. 4. * Author:. *. 5. * Gabriel Renaldo Laureano - laureano@inf.ufsc.br. *. 6. * Leonardo Taglietti. *. 7. *. *. 8. * For more information on ArchC, please visit:. *. 9. * http://www.archc.org. *. 10. - leonardo@inf.ufsc.br. *******************************************************/. 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 {.

(47) 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 59 60 }. return addresses[(tos + 7) % 8]; }.

(48) 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 { 78. if (address == INDF). 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. {.

(49) 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. */.

(50) 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);.

(51) 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 159. ac_instr_counter); 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 177 }. //Empty.

(52) 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);.

(53) 50. 207. if (d == 1). 208. {. 209. write (f, result);. 210. }. 211. else. 212. {. 213. W.write (result);. 214. }. 215. status[Z] = (result == 0);. 216. write_status ();. 217. dprintf ("Result: %X \n\n", result);. 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;. 225. write_status ();. 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;. 234. write_status ();.

(54) 51. 235. dprintf ("Result: %X \n\n", W.read ());. 236 } 237 //!Instruction COMF behavior method. 238 void ac_behavior (COMF) 239 { 240. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 241. char result;. 242. result = ~read (f);. 243. if (d == 1). 244. {. 245. write (f, result);. 246. }. 247. else. 248. {. 249. W.write (result);. 250. }. 251. status[Z] = (result == 0);. 252. write_status ();. 253. dprintf ("Result: %X \n\n", result);. 254 } 255 //!Instruction DECF behavior method. 256 void ac_behavior (DECF) 257 { 258. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 259. char result;. 260. result = read (f) - 1;. 261. if (d == 1). 262. {. 263. write (f, result);.

(55) 52. 264. }. 265. else. 266. {. 267. W.write (result);. 268. }. 269. status[Z] = (result == 0);. 270. write_status ();. 271. dprintf ("Result: %X \n\n", result);. 272 } 273 //!Instruction DECFSZ behavior method. 274 void ac_behavior (DECFSZ) 275 { 276. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 277. char result;. 278. result = read (f) - 1;. 279. if (d == 1). 280. {. 281. write (f, result);. 282. }. 283. else. 284. {. 285. W.write (result);. 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");.

(56) 53. 295. }. 296. dprintf ("Result: %X \n\n", result);. 297 } 298 //!Instruction INCF behavior method. 299 void ac_behavior (INCF) 300 { 301. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 302. char result;. 303. result = read (f) + 1;. 304. if (d == 1). 305. {. 306. write (f, result);. 307. }. 308. else. 309. {. 310. W.write (result);. 311. }. 312. status[Z] = (result == 0);. 313. write_status ();. 314. dprintf ("Result: %X \n\n", result);. 315 } 316 //!Instruction INCFSZ behavior method. 317 void ac_behavior (INCFSZ) 318 { 319. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 320. char result;. 321. result = read (f) + 1;. 322. if (d == 1). 323. {.

(57) 54. 324. write (f, result);. 325. }. 326. else. 327. {. 328. W.write (result);. 329. }. 330. if (result == 0). 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. }. 339. dprintf ("Result: %X \n\n", result);. 340 } 341 //!Instruction IORWF behavior method. 342 void ac_behavior (IORWF) 343 { 344. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 345. char result;. 346. result = W.read () | read (f);. 347. if (d == 1). 348. {. 349. write (f, result);. 350. }. 351. else. 352. {. 353 354. W.write (result); }.

(58) 55. 355. status[Z] = (result == 0);. 356. write_status ();. 357. dprintf ("Result: %X \n\n", result);. 358 }. 359 //!Instruction MOVF behavior method. 360 void ac_behavior (MOVF) 361 { 362. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 363. char result;. 364. result = read (f);. 365. if (d == 1). 366. {. 367. write (f, result);. 368. }. 369. else. 370. {. 371. W.write (result);. 372. }. 373. status[Z] = (result == 0);. 374. write_status ();. 375. dprintf ("Result: %X \n\n", result);. 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));.

(59) 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 { 392. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 393. unsigned char result;. 394. result = read (f);. 395. status = read (STATUS);. 396. sc_uint < 8 > aux_carry;. 397. aux_carry = result;. 398. result = (result << 1) | status[C];. 399. if (d == 1). 400. {. 401. write (f, result);. 402. }. 403. else. 404. {. 405. W.write (result);. 406. }. 407. status[C] = aux_carry[7];. 408. write_status ();. 409. dprintf ("Result: %X \n\n", result);. 410 } 411 //!Instruction RRF behavior method..

(60) 57. 412 void ac_behavior (RRF) 413 { 414. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 415. unsigned char result;. 416. result = read (f);. 417. status = read (STATUS);. 418. sc_uint < 8 > aux_carry;. 419. aux_carry = result;. 420. result = (result >> 1) | (status[C] << 7);. 421. if (d == 1). 422. {. 423. write (f, result);. 424. }. 425. else. 426. {. 427. W.write (result);. 428. }. 429. status[C] = aux_carry[0];. 430. write_status ();. 431. dprintf ("Result: %X \n\n", result);. 432 } 433 //Instruction SUBWF behavior method. 434 void ac_behavior (SUBWF) 435 { 436. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 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 ());.

(61) 58. 442. status[Z] = (result == 0);. 443. if (d == 1). 444. {. 445. write (f, result);. 446. }. 447. else. 448. {. 449. W.write (result);. 450. }. 451. write_status ();. 452. dprintf ("Result: %X \n\n", result);. 453 } 454 //!Instruction SWAPF behavior method. 455 void ac_behavior (SWAPF) 456 { 457. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 458. char high, low, result;. 459. high = read (f) << 4;. 460. low = read (f) >> 4;. 461. dprintf ("New Values: HIGH: %X. 462. result = high | low;. 463. if (d == 1). 464. {. 465. LOW: %X \n", high, low);. write (f, result);. 466. }. 467. else. 468. {. 469. W.write (result);. 470. }. 471. dprintf ("Result: %X \n\n", result);. 472 }.

(62) 59. 473 //!Instruction XORWF behavior method. 474 void ac_behavior (XORWF) 475 { 476. dprintf ("%s 0x%x,%X \n", get_name (), f, d);. 477. char result;. 478. result = W.read () ^ read (f);. 479. if (d == 1). 480. {. 481. write (f, result);. 482. }. 483. else. 484. {. 485. W.write (W.read () ^ read (f));. 486. }. 487. status[Z] = (result == 0);. 488. write_status ();. 489. dprintf ("Result: %X \n\n", result);. 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;.

(63) 60. 501. result = read (f);. 502. result = result & mask;. 503. write (f, result);. 504. dprintf ("Result: %X \n\n", result);. 505 } 506 //!Instruction BSF behavior method. 507 void ac_behavior (BSF) 508 { 509. dprintf ("%s 0x%x,%X \n", get_name (), f, b);. 510. char result, mask;. 511. mask = 0x01 << b;. 512. result = read (f);. 513. result = result | mask;. 514. write (f, result);. 515. dprintf ("Result: %X \n\n", result);. 516 } 517 //!Instruction BTFSC behavior method. 518 void ac_behavior (BTFSC) 519 { 520. dprintf ("%s 0x%x,%X \n", get_name (), f, b);. 521. char result, mask;. 522. mask = 0x01 << b;. 523. result = read (f) & mask;. 524. if (result == 0). 525. {. 526. dprintf ("Bit %X = 0. Skip next instruction.\n", b);. 527. ac_pc += 2;. 528. }.

(64) 61. 529. else. 530. {. 531. dprintf ("Bit %X = 1. Run next instruction.\n", b);. 532. }. 533. dprintf ("Result: %X \n\n", result);. 534 } 535 //!Instruction BTFSS behavior method. 536 void ac_behavior (BTFSS) 537 { 538. dprintf ("%s 0x%x,%X \n", get_name (), f, b);. 539. char result, mask;. 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. }. 551. dprintf ("Result: %X \n\n", result);. 552 } 553 //---------------------------------------------------------------------. 554 //--------------------------------------------------------------------555 //---------Literal Operations-----------------------------------------556 //--------------------------------------------------------------------557 //!Instruction ADDLW behavior method..

(65) 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);. 565. status[Z] = (result == 0);. 566. W.write (result);. 567. write_status ();. 568. dprintf ("Result: %X \n\n", result);. 569 } 570 //!Instruction ANDLW behavior method. 571 void ac_behavior (ANDLW) 572 { 573. dprintf ("%s %X\n", get_name (), k);. 574. char result;. 575. result = W.read () & k;. 576. W.write (result);. 577. status[Z] = (result == 0);. 578. write_status ();. 579. dprintf ("Result: %X \n\n", result);. 580 }. 581 //!Instruction CLRWDT behavior method. 582 void ac_behavior (CLRWDT) 583 { 584 585 }. //Empty.

(66) 63. 586 //!Instruction IORLW behavior method. 587 void ac_behavior (IORLW) 588 { 589. dprintf ("%s %X\n", get_name (), k);. 590. char result;. 591. result = W.read () | k;. 592. W.write (result);. 593. status[Z] = (result == 0);. 594. write_status ();. 595. dprintf ("Result: %X \n\n", result);. 596 } 597 //!Instruction MOVLW behavior method. 598 void ac_behavior (MOVLW) 599 { 600. dprintf ("%s %X\n", get_name (), k);. 601. W.write (k);. 602. dprintf ("Result: %X \n\n", W.read ());. 603 } 604 //!Instruction SUBLW ehavior method. 605 void ac_behavior (SUBLW) 606 { 607. dprintf ("%s %X\n", get_name (), k);. 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 ());. 612. status[Z] = (result == 0);.

(67) 64. 613. W.write (result);. 614. write_status ();. 615. dprintf ("Result: %X \n\n", result);. 616 } 617 //!Instruction XORLW behavior method. 618 void ac_behavior (XORLW) 619 { 620. dprintf ("%s %X\n", get_name (), k);. 621. char result;. 622. result = W.read () ^ k;. 623. W.write (result);. 624. status[Z] = (result == 0);. 625. write_status ();. 626. dprintf ("Result: %X \n\n", result);. 627 } 628 //!Instruction RETLW behavior method. 629 void ac_behavior (RETLW) 630 { 631. dprintf ("%s %X\n", get_name (), k);. 632. W.write (k);. 633. ac_pc = STACK.pop ();. 634. dprintf ("Result: %X \n\n", W.read ());. 635 } 636 //--------------------------------------------------------------------637 //--------------------------------------------------------------------638 //---------Control Operations------------------------------------------.