Um Sistema Integrado Baseado no Processador OpenRISC
Carlos Alexandre Antunes Rodrigues
Dissertação para a obtenção de Grau de Mestre em Engenharia Electrotécnica e de Computadores
Orientador: Prof. José João Henriques Teixeira de Sousa
Júri
Presidente: Prof. Francisco André Corrêa Alegria
Orientador: Prof. José João Henriques Teixeira de Sousa Vogal: Prof. Mário Pereira Véstias
Novembro de 2019
Declarac¸ ˜ao
Declaro que o presente documento ´e um trabalho original da minha autoria e que cumpre todos os requisitos do C´odigo de Conduta e Boas Pr´aticas da Universidade de Lisboa.
Agradecimentos
Em primeiro quero agradecer o Professor Jos´e Sousa por toda a ajuda, durante todo o per´ıodo da tese e mesmo antes.
Tamb´em quero agradecer a todos os meus amigos e colegas de Eng. e Arq. naval e de Eng.
electrot´ecnica e de computadores por toda a ajudar da minha vida dentro do IST. Em especial a ´Iris Pinheiro e o Jorge Miranda porque foram as pessoas que mais me motivaram durante a tese.
Agradec¸o tamb´em `a minha fam´ılia por todo o esforc¸o que foi necess´ario fazer durante toda a minha vida escolar.
Resumo
Esta tese tem como objectivo desenvolver um sistema integrado (System on Chip (SoC)) gen´erico usando componentesopen source, para que empresas com meios financeiros reduzidos usarem nos produtos que desenvolvem, de acordo com as suas necessidades. A realizac¸˜ao deste desenvolvimento permitiu concluir das vantagens e dificuldades de tal abordagem.
Tornou-se evidente que ter´ıamos de nos associar a uma comunidade de desenvolvimento dehard- ware openSource. Opt´amos pela comunidade OpenRISC por ser uma comunidade bastante activa e por dispor de um processador com requisitos m´ınimos de processamento. De forma a se poder dar resposta a v´arios requisitos comuns, foram desenvolvidos v´arios m´odulos perif´ericos para este SoC.
O primeiro requisito estudado foi a necessidade de executar software obtido de uma mem´oria n˜ao vol´atil. A soluc¸˜ao encontrada foi a de utilizar um cart˜aoSecurity Digital(SD) para armazenar o software que posteriormente ´e transferido para o SoC para execuc¸˜ao. O cart˜ao utiliza uma interface Serial Peripheral Interface(SPI) para a transferˆencia de dados. Desta forma foi necess´ario garantir o correcto funcionamento de um n´ucleo mestre SPI open source, e desenvolver de raiz um escravo SPI, dado que este n´ucleo n˜ao se encontrava dispon´ıvel emopen source. Foi tamb´em necess´ario ter dispon´ıvel uma mem´oria permanente de arranque (Boot ROM) que contivesse o programa que fizesse a c´opia do software que se encontrava no cart˜ao SD para a mem´oria de principal.
O segundo requisito contemplado foi o de guardar dados importantes tamb´em em mem´orias n˜ao vol´ateis, e para isso foi utilizada uma mem´oria com interfaceInter-Integrated Circuit (I2C). Adoptou-se um n´ucleo I2C mestreopen source, ao qual foi necess´ario fazer correcc¸˜oes, tendo-se desenvolvido de raiz o escravo I2C, uma vez que este n˜ao se encontrava dispon´ıvel.
Outra especificac¸˜ao era o SoC disponibilizar uma interface simples, ass´ıncrona e full duplex para serem acoplados m´odulos desenvolvidos por terceiros. Para tal foi desenvolvida uma interface que utiliza duas mem´orias do tipoFrist In First Out (FIFO), uma para cada sentido, preenchendo assim os requisitos.
Por fim, para garantir o correcto funcionamento do SoC, foi desenvolvida uma ferramenta de teste e verificac¸˜ao do sistema. Esta ferramenta permite facilmente adicionar novos testes, tornando assim conveniente a verificac¸˜ao do correcto funcionamento do SoC durante o desenvolvimento.
A conclus˜ao deste trabalho foi que a vantagem econ´omica de utilizar componentes de hardware open sourcen˜ao ´e muito evidente. A baixa qualidade dos componentes dispon´ıveis e o trabalho que d´a coloc´a-los num n´ıvel de desempenho satisfat´orio fazem com que a vantagem da gratuitidade dos componentes nem sempre se traduz numa vantagem econ´omica. Actualmente, com o aparecimento da arquitectura de processador RISC-V, muitos destes problemas foram aliviados mas muito existe ainda por se fazer neste dom´ınio.
Palavras-chave:
OpenRISC, Sistema em um chip, OpenSource, SPI, I2C, OpenHardWareAbstract
This thesis aims to develop an integrated system ( ac SoC) using open source components, so that companies with lower financial resources can use them in the products they develop in accordance with their needs. The realization of this development allowed us to conclude of the advantages and difficulties of such an approach.
It became evident that we would have to associate with an open source community for hardware development. We opted for the OpenRISC community for being a very active community and for having a processor with minimum processing requirements. To respond to various common requirements, several peripheral modules have been developed for this SoC.
The forst requirement studied was the need to run software obtained from a non-volatile memory.
The solution found was to use an SD card to store the software, that is later transferred to the SoC for execution. The card uses an SPI interface for data transfer. Thus, the correct functionality of an open source SPI master core was verified and a slave SPI core was developed from scratch, since it was not available open source. It was also necessary to have available a bootable permanent memory (Boot ROM) that contains the program for copying the software from the SD card to the main memory.
The second requirement was to keep important data in non-volatile memories, using a memory with an I2C interface. A master I2C open source core has been adopted, which needed some corrections, and it was necessary to develop a peripheral slave that was not available at the time when the SoC was developed.
Another specification was that of providing a simple interface, asynchronous and full duplex, to inter- face with modules developed by the 3rd parties. For this purpose an asynchronous FIFO interface has been developed, having one FIFO in each direction, thus fulfilling the requirements.
Finally, to ensure the proper functioning of the SoC, a system test and verification tool was developed.
This tool allows easy addition of new tests, which is convenient for verification of the SoC during its development.
The conclusion of this work was that the economic advantage of using open source hardware com- ponents is not obvious. The low quality of the available components and the work required to place them at a satisfactory performance level do not always translate into an economic advantage. Today, with the advent of the RISC-V processor architecture, many of these problems have been alleviated but much remains to be done in this domain.
Keywords:
OpenRISC, System on chip, OpenSource, SPI, I2C, OpenHardWareConte ´ udo
Agradecimentos . . . iii
Agradecimentos . . . v
Resumo . . . vii
Abstract . . . ix
Lista de Tabelas . . . xv
Lista de Figuras . . . xviii
Lista de Acr´onimos . . . xix
1 Introduc¸ ˜ao 1 1.1 Contexto . . . 2
1.2 Motivac¸˜ao . . . 2
1.3 Objectivos . . . 2
1.4 Desafios . . . 2
2 Enquadramento 5 2.1 OpenRISC . . . 5
2.1.1 Arquitectura . . . 6
2.1.2 Barramento Wishbone . . . 6
2.1.3 Toolchain . . . 9
2.1.4 OrpSoc . . . 10
2.2 Ferramentas . . . 11
2.2.1 Or1ksim . . . 12
2.2.2 Verilator . . . 12
2.2.3 Icarus Verilog . . . 13
2.2.4 Placa com FPGA . . . 13
2.2.5 OpenOCD . . . 15
2.3 Perif´ericos . . . 16
2.3.1 Boot ROM . . . 16
2.3.2 UART . . . 16
2.3.3 GPIO . . . 17
2.3.4 Interface FIFO . . . 17
2.3.5 I2C . . . 18
2.3.6 SPI . . . 18
3 Interface SPI 19 3.1 Mestre SPI . . . 20
3.2 Escravo SPI . . . 23
3.3 Diagramas temporais . . . 25
3.3.1 Selecc¸˜ao de escravos . . . 25
3.3.2 Transferˆencia de Dados . . . 25
4 I2C 27 4.1 Mestre I2C . . . 28
4.2 Escravo I2C . . . 30
4.3 Diagrama temporal . . . 32
4.3.1 Start bit . . . 32
4.3.2 Stop bit . . . 33
4.3.3 Restart bit . . . 33
4.3.4 Dados . . . 33
4.3.5 ACK . . . 34
4.3.6 NACK . . . 34
5 Interface FIFO 35 6 Boot ROM 39 6.1 Testes de verificac¸˜ao . . . 41
6.1.1 Teste de leitura SPI . . . 41
6.1.2 Teste de escrita na mem´oria principal . . . 41
7 Controladores de dispositivos 43 7.1 Controlador SPI . . . 43
7.2 Controlador I2C . . . 43
7.3 Controlador Interface FIFO . . . 44
8 Testes de funcionamento 45 8.1 Informac¸˜ao para cada teste . . . 47
8.2 Adicionar novos testes . . . 48
8.3 Testes desenvolvidos . . . 48
8.3.1 UART . . . 48
8.3.2 SPI . . . 49
8.3.3 I2C . . . 49
8.3.4 Interface FIFO . . . 50
8.3.5 Boot ROM . . . 50
9 Conclus ˜ao 53 9.1 Trabalho realizado . . . 53 9.2 Trabalho Futuro . . . 55
Bibliografia 58
Lista de Tabelas
2.1 Tabela dos sinais da interface Wishbone. . . 8
3.1 Pinos do cart˜ao SD com interface SPI . . . 19
3.2 Tabela de sinais da interface SPI mestre . . . 22
3.3 Tabela de registos da interface SPI master . . . 22
3.4 Tabela de sinais da interface do n´ucleo SPI escravo. . . 24
4.1 Tabela de sinais do n´ucleo I2C master . . . 30
4.2 Tabela de registos da interface I2C mestre . . . 30
4.3 Tabela de sinais da interface I2C escravo . . . 32
5.1 Tabela de sinais da interface FIFO . . . 37
5.2 Tabela de registos do m´odulo interface FIFO . . . 37
8.1 Tabela com os parˆametros existentes na func¸˜ao de correr testes . . . 47
Lista de Figuras
1.1 Diagrama de blocos de um SoC ARM . . . 1
1.2 SOC pretendido . . . 3
2.1 Diagrama de blocos do processador OpenRISC1200 . . . 6
2.2 Interfaces Wishbone . . . 7
2.3 Diagrama de blocos da arquitectura Wishbone. . . 8
2.4 Diagramas temporais Wishbone . . . 9
2.5 Organizac¸˜ao do sistemas e n´ucleos da OpenRISC . . . 11
2.6 Diagrama de ficheiros do ORPSoC . . . 12
2.7 Diagrama do simulador Verilator . . . 13
2.8 Diagrama do simulador Icarus . . . 14
2.9 Diagrama do funcionamento da placa de FPGA . . . 15
2.10 Diagrama do OpenOCD . . . 16
2.11 Diagrama temporal da UART . . . 17
3.1 Cart˜ao SD com interface SDI . . . 19
3.2 Sistema de comunicac¸˜ao SPI com 1 mestre e 3 escravos . . . 20
3.3 Fluxo dos dados no n´ucleo mestre SPI . . . 21
3.4 Excerto de leituraburst . . . 23
3.5 Excerto de leitura em simples . . . 23
3.6 Estrutura e fluxo de dados no n´ucleo SPI escravo . . . 24
3.7 Diagrama temporal da selecc¸˜ao do escravo . . . 25
3.8 Diagrama temporal do envio de dados pelo mestre . . . 26
3.9 Diagrama temporal do envio de dados pelo escravo . . . 26
4.1 Sistema de comunicac¸˜ao I2C com um mestre e v´arios escravos . . . 28
4.2 Estrutura e fluxo de dados do n´ucleo mestre de I2C . . . 29
4.3 Fluxo de dados do n´ucleo escravo I2C . . . 31
4.4 Bit de inicializac¸˜ao . . . 32
4.5 Bit de paragem . . . 33
4.6 Bit de recomec¸o . . . 33
4.7 Bit de dados com valor l´ogico ’1’ . . . 33
4.8 Bit de dados com valor l´ogico ’0’ . . . 34
4.9 Sinal Ack . . . 34
4.10 Sinal NAck . . . 34
5.1 Esquem´atico do sistema de comunicac¸˜ao FIFO. . . 35
5.2 Fluxo de dados do m´odulo Interface FIFO . . . 36
6.1 Fluxograma da boot ROM . . . 40
8.1 Diagrama da plataforma de testes usando o FuseSoc. . . 46
Lista de Acr ´ onimos
ACK Acknowledge
ADS Advanced Debug System
BSD Berkeley Software Distribution
BIOS Basic Input Output System
DSP Digital Signal Processing
EEPROM Electrically-Erasable Programmable Read-Only Memory
FIFO Frist In First Out
FPGA Field Programmable Gate Array
GPIO General Purpose Input/Output
IP Intellectual Property
I2C Inter-Integrated Circuit
JTAG Joint Test Action Group
MISO Master In Slave Out
MOSI Master Out Slave In
NACK Negative-Acknowledge
OpenOCD Open On-Chip Degug0ger
ORPSoC OpenRISC Reference Platform System-on-Chip
OR1200 OpenRISC12000
RISC Reduced Instruction Set Computing
ROM Read-Only Memory
RSP Remote Serial Protocol
SCL Serial Clock
SCLK Serial Clock
SD Security Digital
SDA Serial Data
SoC System on Chip
SPI Serial Peripheral Interface
SS Slave Select
UART Universal Asynchronous Receiver/Transmitter
USB Universal Serial Bus
Cap´ıtulo 1
Introduc¸ ˜ao
Um sistema integrado, em inglˆes System On Chip SoC, ´e um circuito integrado que inclui todas as funcionalidades de um sistema electr´onico num ´unico dispositivo.
Um SoC ´e constitu´ıdo tipicamente por v´arios m´odulos interligados entre si por barramentos. Os m´odulos podem ser separados por grupos conforme as suas principais funcionalidades, sendo os prin- cipais grupos os seguintes: processamento, mem´oria, clock, perif´ericos, interfaces externas, interfaces anal´ogicas e gestores de energia. Na figura 1.1 pode observar-se um exemplo de um diagrama de blocos de um SoC centrado num processador ARM, onde se vˆeem os v´arios n´ucleos e os barramentos de ligac¸˜ao entre eles.
Figura 1.1:Diagrama de blocos de um SoC ARM
Os SoC tˆem uma vasta gama de utilizac¸˜ao, desde um simples rel´ogio at´e sistemas avanc¸ados para sat´elites ou para a ind´ustria autom´ovel. Com o aparecimento de sistemas como o Arduino, cada vez
mais os SoC s˜ao utilizados em projectos de pequena escala, permitindo a pessoas com pouco conhe- cimento na ´area programar e depurar c´odigo para os seus projectos utilizando o SoC. A sua utilizac¸˜ao tem vantagens como: baixo custo, baixo consumo de energia e pequenas dimens˜oes. Existem tamb´em desvantagens associados ao baixo poder de c´alculo comparado com um computador convencional.
Com uma ´area t˜ao vasta de aplicac¸˜oes n˜ao ´e de estranhar que existam v´arias empresas, muitas delas startups, a desenvolver SoC’s, optimizados de acordo com o que ´e pretendido, para fins total- mente distintos, ou a contratarem empresas da especialidade para desenvolverem m´odulos do SoC `a sua medida.
1.1 Contexto
Este trabalho desenrolou-se no contexto de uma startup em formac¸˜ao, que necessitava de um SoC gen´erico para poder configurar e produzir uma linha de produtos do tipo n´ucleo de propriedade in- telectual (IP core). Na pesquisa do SoC ideal foram encontradas diferentes possibilidades, algumas comerciais que passavam pelo licenciamento de propriedade intelectual de terceiros e apresentavam custos demasiado elevados. Lanc¸ou-se ent˜ao este projecto para ajudar a procurar uma soluc¸˜ao que passasse pelo desenvolvimento de um SoC pela pr´opria startup usando componentesopen source.
1.2 Motivac¸ ˜ao
A motivac¸˜ao deste trabalho ´e ent˜ao a de desenvolver um SoC gen´erico, usando apenas componentes open source, que possa ser facilmente configurado para produzir produtos diferenciados, reduzindo assim o esforc¸o de desenvolvimento e o capital necess´ario [1].
1.3 Objectivos
O objectivo primordial deste trabalho ´e o desenvolvimento do SoC gen´erico descrito na secc¸˜ao anterior.
Os requisitos do SoC podem ver-se na figura 1.2.
O SoC ter´a de ter a capacidade de processamento necess´aria para receber, processar e enviar dados por v´arias interfaces: I2C, SPI, FIFO, Universal Asynchronous Receiver/Transmitter (UART), General Purpose Input/Output(GPIO).
O SoC ´e para ser usado em locais de dif´ıcil acesso e ter´a que ter um baixo consumo, permitindo que a bateria funcione durante o maior tempo poss´ıvel.
1.4 Desafios
No decorrer deste trabalho de dissertac¸˜ao foram encontrados v´arios desafios dos quais importa salien- tar os seguintes:
Figura 1.2:SOC pretendido
• desenvolvimento e teste de um sistema sintetiz´avel que preencha todas as necessidades referi- das. Sendo sintetiz´avel poder´a ser integrado em v´arios projectos de forma eficiente.
• desenvolvimento e teste de uma interface de FIFO ass´ıncrona necess´aria para a comunicac¸˜ao entre o SoC e m´odulos que funcionam a outras frequˆencias.
• desenvolvimento de uma mem´oria de arranque (Boot ROM) que carregue para a mem´oria prin- cipal o programa que se encontra numaElectrically-Erasable Programmable Read-Only Memory (EEPROM).
Cap´ıtulo 2
Enquadramento
Existem duas abordagens para o desenvolvimento de um SoC. A primeira consiste no desenvolvi- mento de um sistema por completo incluindo processador, barramento e protocolos de comunicac¸˜ao necess´arios, o que se torna complicado de idealizar e executar no tempo dispon´ıvel. Por outro lado, po- demos juntar-nos a uma das v´arias comunidadesopen sourcedehardwarej´a existentes, onde algumas das v´arias funcionalidades foram j´a idealizadas ou desenvolvidas, o que permite ainda contribuir com alguns melhoramentos ou resoluc¸˜oes de problemas existentes nos projectos da comunidade escolhida.
Uma das maiores [2] comunidades de open source de hardware ´e a comunidade OpenCores (www.opencores.org), com aproximadamente 1400 projectos e 270000 utilizadores registados. Os projectos desenvolvidos por esta comunidade usam linguagens de descric¸˜ao de hardware. A maio- ria dos projectos da comunidade s˜ao desenvolvidos em Verilog, uma das linguagens mais utilizadas na descric¸˜ao dehardware.
A associac¸˜ao a esta comunidade tem v´arias vantagens desde logo a facilidade de reconfigurar v´arias ferramentas de ajuda ao desenvolvimento do SoC, com destaque para a ferramenta de configurac¸˜ao de build e de simulac¸˜ao do SoC. Outra n˜ao menos importante ´e j´a ter dispon´ıvel tudo o que ´e necess´ario para o Debug do software.
2.1 OpenRISC
O principal projecto da comunidade OpenCores ´e o projecto OpenRISC [3], que tem como objectivo desenvolver processadores com arquitecturaReduced Instruction Set Computing(RISC).
A primeira vers˜ao da arquitectura ´e denominada OpenRISC1000, sendo um processador de 32 ou 64 bits com a opc¸˜ao de v´ırgula flutuante e suporte para processamento vectorial [3]. A comunidade OpenCores fez o primeiro processador deste tipo dando-lhe o nome OpenRISC12000 (OR1200) [4].
Este ´e escrito em Verilog sintetiz´avel e tem uma capacidade de processamento semelhante `a do pro- cessador ARM10 [5]. Algumas empresas e organizac¸˜oes desenvolveram SoCs com base neste pro- cessador, entre as mais conhecidas est˜ao a Samsung e a NASA.
O segundo processador desenvolvido por esta comunidade tem o nome OpenRISC2000 [6], e pre-
tende ser um sucessor do anterior com o qual ´e compat´ıvel. ´E um projecto modular, adaptado para o uso de multi-n´ucleos e destinado a sistemas embebidos. Usa dados de 16 e 32 bits, n˜ao tem suporte para 64 bits e pode ser implementado numa Field Programmable Gate Array (FPGA) [7, 8] de porte pequeno ou m´edio.
2.1.1 Arquitectura
A arquitectura do processador OR1200 est´a ilustrada na figura 2.1.
O [4] processador tem um n´ucleo de processamento de instruc¸˜oes empipeline com 5 andares:
Fetch, Decode, Execute, Memory, Writeback. Tem tamb´em uma unidade de Digital Signal Proces- sing (DSP) acoplada. Existemcachese unidades de gest˜ao de mem´oria tanto para instruc¸˜oes como para dados. Adicionalmente, possui uma unidade de depurac¸˜ao que permite depurar c´odigo em tempo real [9], um controlador de interrupc¸˜oes program´avel, um m´odulo de gest˜ao de energia e um tempori- zador. As unidades mencionadas tˆem a capacidade de serem facilmente removidas caso n˜ao sejam necess´arias, permitindo assim que o processador tenha dimens˜oes reduzidas e um baixo consumo de energia.
Existem ainda duas interfaces Wishbone que pertencem `a arquitectura base do processador: uma pertence `a interface de instruc¸˜oes e a outra `a interface de dados. Estas duas interfaces fazem a convers˜ao da interface nativa do CPU para a interface Wishbone que ´e recebida pelos perif´ericos do SoC.
Figura 2.1:Diagrama de blocos do processador OpenRISC1200
2.1.2 Barramento Wishbone
A interface de barramento Wishbone [10] ´ehardware open source, permite a comunicac¸˜ao entre v´arios n´ucleos dentro de um SoC. Esta interface ´e bastante utilizada em CPUs e perif´ericos open source,
onde se destacam muitos dos projectos da comunidade OpenCores, sendo recomendado que todos os n´ucleos tenham dispon´ıvel uma interface Wishbone. O barramento Wishbone foi desenvolvido pela Silicore Corporation em 1999 e disponibilizado para o dom´ınio p´ublico numa biblioteca VDHL. A partir de 2002 a comunidade OpenCores tornou-se tamb´em patrocinadora do Wishbone, tendo uma p´agina dedicada `a interface onde est˜ao dispon´ıveis novas revis˜oes.
A interface Wishbone pode utilizar-se em quatro tipos de arquitectura, como mostrado na figura 2.2.
A interligac¸˜ao ponto a ponto (figura 2.2(a)) permite apenas a ligac¸˜ao a um perif´erico. Este tipo de ligac¸˜ao n˜ao ´e normalmente utilizada num SoC, uma vez que habitualmente estes s˜ao constitu´ıdos por v´arios perif´ericos. A interface de barramento partilhado (figura 2.2(b)) permite a utilizac¸˜ao de v´arios mestres e v´arios escravos visto que o barramento ´e partilhado, ou seja, quando um mestre utiliza o barramento, os outros mestres tˆem de aguardar que este fique dispon´ıvel. O controlo ´e feito por um ´arbitro que decide qual o mestre que controla o barramento num dado momento. por exemplo, o comutador de barra (figura 2.2(c)) ´e utilizado numa tipologia multi-n´ucleo. Este permite que dois mestres comuniquem com escravos diferentes em simultˆaneo, sendo semelhante ao barramento partilhado mas com uma maior taxa de transferˆencia de dados. Por ´ultimo apresenta-se a interligac¸˜ao de fluxo de dados (figura 2.2(d)), onde a informac¸˜ao flui de perif´erico para perif´erico, e em que todos os perif´ericos tˆem de ter uma interface de escravo e outra de mestre.
(a) Interligac¸˜ao ponto a ponto (b) Interligac¸˜ao de barramento partilhado
(c) Interligac¸˜ao comutador de barra(crossbar switch) (d) Interligac¸˜ao de fluxo de dados Figura 2.2:Interfaces Wishbone
A interligac¸˜ao utilizada no desenvolvimento de um SoC com apenas uma unidade de processamento
´e o barramento partilhado, porque tem v´arios perif´ericos dispon´ıveis e por ser de simples implementac¸˜ao (figura 2.3). Toda a gest˜ao da interface Wishbone ´e feita no m´odulo Intercon, sendo este constitu´ıdo por v´arios elementos como multiplexadores e ´arbitros Wishbone. Como se pode ver na figura 2.3, os m´odulos Wishbone de dados e de instruc¸˜oes do processador, mencionados na figura 2.1, est˜ao ligados a gestores de acessos. O Wishbone de dados encontra-se ligado a um multiplexer que envia os dados para o perif´erico correspondente conforme o enderec¸o atribu´ıdo a cada perif´erico. Um ´arbitro faz o
controlo de acesso `a mem´oria principal entre o acesso de dados e das instruc¸˜oes. Como o SoC s´o tem dispon´ıvel uma mem´oria, esta ´e utilizada para guardar dados e tamb´em para guardar instruc¸˜oes.
Para adicionar um novo perif´erico ao SoC, a interface do escravo ´e ligada ao multiplexer de Wishbone de dados e, `a semelhanc¸a dos outros perif´ericos da figura 2.3, tem de ser atribu´ıdo ao perif´erico um conjunto de enderec¸os dispon´ıveis, para que o multiplexer saiba a que perif´erico corresponde aquele pedido.
Figura 2.3:Diagrama de blocos da arquitectura Wishbone.
A interface Wishbone ´e constitu´ıda por 12 sinais distintos que se encontram descritos na tabela 2.1, sendo que a maior parte dos sinais, com excepc¸˜ao de wbm adr i, wbm dat i, wbm dat o e wbm sel i, s˜ao de apenas um bit. A tabela indica a direcc¸˜ao dos sinais observada do lado do perif´erico.
Nome Direcc¸˜ao Largura(bits) Descric¸˜ao
wbm cki i Input 1 Clock do sistema para a interface Wishbone.
wbm rst i Input 1 Sinal deReset(activo com valor l´ogico ’1’).
wbm cyc i Input 1 Validac¸˜ao da informac¸˜ao noBus.
wbm adr i Input 32 Enderec¸o para escrita ou leitura no perif´erico.
wbm dat i Input 32 Dados enviados para o perif´erico.
wbm dat o Output 32 Dados enviados pelo perif´erico.
wbm sel i Input 4 Selecciona Byte para escrever ou ler.
wbm ack o Output 1 Sinal deAcknowledge(ACK).
wbm err o Output 1 Indica um ciclo anormal: ocorreu um encerramento.
wbm we i Input 1 Sinal de leitura ou escrita, valor l´ogico ’1’ escreve.
wbm stb i Input 1 Valida os dados transmitidos.
wbm rty 0 Output 1 Indica se a interface n˜ao est´a pronta pra receber ou enviar dados.
Tabela 2.1:Tabela dos sinais da interface Wishbone.
A interface Wishbone mestre ´e controlada pelas caches de dados ou instruc¸˜oes, como mostrado na figura 2.1, dependendo se se trata da interface de dados ou de instruc¸˜oes respectivamente. As leituras e as escritas podem ser simples – leitura de apenas uma posic¸˜ao de mem´oria – ou burst – em que s˜ao feitos quatro acessos sequenciais. Isto ´e definido no c´odigo e corresponde ao tamanho daMemory Management Unit(MMU). Na figura 2.4 podem ser observados v´arios diagramas temporais de leituras e escritas na mem´oria feitas pelas caches.
As figuras 2.4(a) e 2.4(b) correspondem a diagramas temporais referentes ao m´odulo Data Cache,
em que o sinal dcfsm burst acciona uma leitura ou escrita em burst. Na primeira figura temos uma leitura simples: como se pode ver o sinal de burst est´a com o valor l´ogico de ’0’ e o sinal biu we i tamb´em se encontra com o valor l´ogico de ’0’, indicando que ´e uma leitura. Tamb´em se pode ver que o sinal biu sel i ´e o primeiro a ser definido e tem o valor 4 em hexadecimal, indicando que ´e para ser lido apenas o segundo byte mais significativo do sinal biu dat o.
Na figura 2.4(b) temos uma escrita simples. Neste caso ainda temos o sinal dcfsm burst com o valor l´ogico de ’0’, mas o sinal biu we i j´a tem o valor l´ogico de ’1’, accionado ao mesmo tempo que os sinais de validac¸˜ao biu cyc i e biu stb i. J´a neste caso o sinal biu sel i com o valor F em hexadecimal indica que todos os bytes de biu dat i s˜ao para ser escritos.
Por ´ultimo na figura 2.4(c) ´e apresentado um diagrama temporal referente `a cache de instruc¸˜oes, onde ´e representada uma leitura emburst. Neste caso podemos ver que o sinal icfsm burst tem o valor l´ogico ’1’, e que no sinal biu adr i o enderec¸o se mant´em at´e receber o primeiro ACK. A partir da´ı este ´e incrementado de quatro em quatro posic¸˜oes de mem´oria (organizada ao byte) em cada flanco ascendente.
Clock dcfsm_burst biu_dat_i
biu_adr_i 90000005
biu_cyc_i biu_stb_i biu_we_i
biu_sel_i 4
biu_cab_i
biu_dat_o 00000000
biu_ack_o biu_err_o
(a) Diagrama temporal do ciclo de leitura simples
Clock dcfsm_burst
biu_dat_i 00000000
biu_adr_i 007FFF40
biu_cyc_i biu_stb_i biu_we_i
biu_sel_i F
biu_cab_i biu_dat_o biu_ack_o biu_err_o
(b) Diagrama temporal do ciclo de escrita simples
Clock icfsm_burst biu_dat_i
biu_adr_i 0000D650 0000D654 0000D658 0000D65C
biu_cyc_i biu_stb_i biu_we_i
biu_sel_i F
biu_cab_i
biu_dat_o 10000006 15000000 9C63FFFF BC430001
biu_ack_o biu_err_o
(c) Diagrama temporal do ciclo de leitura burst Figura 2.4:Diagramas temporais Wishbone
2.1.3 Toolchain
Umatoolchain [11] ´e um conjunto de ferramentas de programac¸˜ao que permite criar programas. Nor- malmente, uma toolchain simples disponibiliza um compilador, um linker para fazer a montagem do c´odigo compilado num programa execut´avel, bibliotecas que fornecem uma interface com o sistema operativo e umdebugger. Uma dastoolchainsmais utilizadas para desenvolver programas em C ´e a toolchainda GNU, sendo vital para o desenvolvimento de Linux, sistemas operativosBerkeley Software Distribution(BSD) esoftware para sistemas embebidos. Atoolchain da GNU disponibiliza mais algu- mas ferramentas adicionais, como por exemplo a ferramenta para compilac¸˜ao autom´atica vulgarmente
conhecida porMake.
Por ser bastante utilizada em desenvolvimento desoftware, v´arias comunidades utilizam atoolchain da GNU. No entanto, o processador da comunidade OpenRISC ainda n˜ao ´e suportado oficialmente pela toolchainda GNU. Por essa raz˜ao a comunidade adicionou o seu processador a duas bibliotecas de C:
a Newlib e a uClibc. A Newlib [12] ´e uma biblioteca j´a testada e utilizada desde a vers˜ao 1.18.0, com suporte de placas, sendo pequena, simples e a melhor para o desenvolvimento de aplicac¸˜oes embare- metal, ou seja, sem sistema operativo. A uClibc [13] ´e uma biblioteca de C para sistemas embebidos donde foram removidas algumas partes do padr˜ao C, mas ainda disp˜oe de todas as funcionalidades necess´arias a um sistema operativo, e ´e ideal para sistemas embebidos suportando processadores ARM, amd64 e i386.
A biblioteca Newlib ´e utilizada no desenvolvimento de aplicac¸˜oes em bare-metal por isso ´e ne- cess´ario indicar ao compilador para fazer alinkagempara uma placa espec´ıfica utilizando aflag-mbo- ard”. Existem j´a algumasplacaspredefinidas como or1ksim (simulador or1ksim sem UART), or1ksim- UART (simulador or1ksim com UART), e a placa de FPGA de0 nano da Terasic. Quando indicamos com a flag qual ´e a placa que utilizamos, o compilador usa um ficheiro com o mesmo nome, j´a pr´e- compilado, que cont´em informac¸˜oes importantes sobre a placa como a frequˆencia de rel´ogio, enderec¸o base e tamanho da mem´oria principal, enderec¸o base ebaud rateda UART e o n´umero IRQ (n´umero do pedido de interrupc¸ao) da UART. ´E poss´ıvel criar um ficheiro com as propriedades da placa que pretendemos atrav´es da criac¸˜ao de um ficheiro com o nome da placa e com a extens˜ao (.S).
2.1.4 OrpSoc
A comunidade OpenRISC apercebeu-se da necessidade de uma plataforma para facilitar o desen- volvimento e a modelac¸˜ao de um SoC. Por esse motivo desenvolveram a plataformaOpenRISC Refe- rence Platform System-on-Chip(ORPSoC) [14], destinada ao desenvolvimento e verificac¸˜ao de n´ucleos Intellectual Property (IP) para o SoC. Para al´em destes objectivos teria de ser simples de usar, tanto por utilizadores experientes como por utilizadores sem qualquer experiˆencia, permitindo assim simular e sintetizar o hardwarefacilmente. A plataforma encontra-se separada do reposit´orio onde se encon- tram os SoC’s e os n´ucleos, permitindo assim que a mesma seja utilizada por outras identidades que pretendam desenvolver um SoC.
O reposit´orio onde se encontram os sistemas e os n´ucleos apresenta a organizac¸˜ao ilustrada na figura 2.5, sendo que no caso do OpenRISC o reposit´orio tem o nome de OrpSoc-cores. Dentro deste reposit´orio existem duas pastas: cores e systems.
Dentro da pasta systems est˜ao todos os SoC’s desenvolvidos ou em desenvolvimento, cada um com a sua pasta espec´ıfica. Dentro de cada SoC existem v´arios ficheiros onde dois deles s˜ao bas- tante importantes e tˆem de ter o nome do sistema com as extens˜oes .core e .system. Por exemplo, de0 nano.core e de0 nano.system, caso seja a placa sistema de0 nano. O ficheiro .system tem a descric¸˜ao do sistema e a localizac¸˜ao dos ficheiros necess´arios para sintetiz´a-lo para uma determinada FPGA. J´a o ficheiro .core cont´em todas as dependˆencias do sistema em relac¸˜ao aos n´ucleos, tendo
tamb´em uma secc¸˜ao com as v´arias ferramentas de simulac¸˜ao. Para cada uma descriminam-se as informac¸˜oes necess´arias para a compilac¸˜ao, tal como o ficheiro de topo do SoC, ficheiros detestbench e as flags de compilac¸˜ao.
A pasta cores cont´em os v´arios n´ucleos, cada um numa pasta, onde ´e obrigat´orio ter o ficheiro com a extens˜ao .core que cont´em uma descric¸˜ao do n´ucleo, a dependˆencia de outros n´ucleos e o nome dos ficheiros de descric¸˜ao do n´ucleo. ´E poss´ıvel que os ficheiros de descric¸˜ao n˜ao estejam no reposit´orio. Nesse caso, o ficheiro tamb´em cont´em uma secc¸˜ao que indica a localizac¸˜ao e n´umero de revis˜ao dos ficheiros no servidor deSubversion(programa de controlo de vers˜oes) da comunidade. A plataforma ORPSoC utiliza esta informac¸˜ao para automaticamente descarregar os ficheiros dos n´ucleos da Internet, no caso de n˜ao estarem presentes no reposit´orio.
Figura 2.5:Organizac¸˜ao do sistemas e n´ucleos da OpenRISC.
Cada sistema que se encontra na pasta systems ´e constitu´ıdo por v´arios n´ucleos que se encontram na pasta cores, e cada n´ucleo pode depender ou n˜ao de um ou mais n´ucleos. Um n´ucleo descreve um n´ucleo, tal como um processador ou um perif´erico. Um sistema descreve como esses n´ucleos est˜ao interligados entre si, tornando a criac¸˜ao de novos sistemas mais simples, n˜ao sendo necess´ario ter c´odigo replicado de cada n´ucleo para cada sistema, sendo assim mais f´acil manter todos os n´ucleos actualizados.
A figura 2.6 representa o sistema de ficheiros criado pela plataforma ORPSoC, o qual se encontra di- vidido por utilidade. Na pasta ORPSoC encontram-se ficheiros que disponibilizam utilit´arios b´asicos, na pasta Build encontram-se as ferramentas para sintetizar o SoC e na pasta Simulator est˜ao dispon´ıveis os procedimentos para a execuc¸˜ao em alguns simuladores. A pasta provider destina-se a descarregar os n´ucleos necess´arios para o SoC que ainda n˜ao se encontrem dispon´ıveis localmente.
Durante o desenvolvimento desta tese a comunidade OpenRISC ponderou que esta ferramenta poderia ser utilizada para o desenvolvimento de outros SoC’s, sem especificamente envolver processa- dores OpenRISC. Desta forma a ferramenta tornou-se independente da comunidade sendo o seu nome alterado para FuseSoC.
2.2 Ferramentas
No desenvolvimento de software espec´ıfico para um SoC, quando este ainda n˜ao se encontra dispon´ıvel fisicamente, ´e importante dispor de v´arias ferramentas de simulac¸˜ao e/ou emulac¸˜ao, pois torna-se dis- pendioso e demorado criar um SoC e s´o posteriormente testar a aplicac¸˜ao.
Figura 2.6:Diagrama de ficheiros do ORPSoC.
2.2.1 Or1ksim
O Or1ksim [15, 16] ´e um simulador de um SoC com arquitectura OpenRISC 1000 desenvolvido em C.
Pretende-se que este simulador seja aut´onomo, permita uma simulac¸˜ao r´apida facilitando a an´alise do correcto funcionamento do c´odigo e a avaliac¸˜ao de desempenho do SoC, seja de f´acil configurac¸˜ao permitindo alterar o processador e o tamanho das mem´orias, permita a adic¸˜ao de novos perif´ericos e a utilizac¸˜ao dodebuggerremoto. O Or1ksim n˜ao simula o que est´a descrito no sistema ORPSoC; quando se faz uma alterac¸˜ao no SoC essa alterac¸˜ao tem de ser feita posteriormente na configurac¸˜ao Or1ksim.
Mas ´e ´optimo para testarsoftwareem desenvolvimento por ser bastante r´apido a executar.
2.2.2 Verilator
O Verilator [17] ´e uma ferramenta que converte o c´odigo Verilog que descreve o SoC em SystemC [18]
ou num objecto em C++. Esse objecto necessita de ser instanciado numa testbench que pode ser escrita em C++ ou SystemC, de acordo como foi convertido anteriormente. A testbench controla o sinal de rel´ogio, podendo tamb´em excitar os sinais de entrada e efectuar a leitura nos sinais de sa´ıda, bem como em qualquer sinal no interior do SoC, tal como se pode ver na figura 2.7. O Verilator
´e um simulador que s´o suporta dois estados nos sinais: valor l´ogico ’1’ ou valor l´ogico ’0’. Este ´e bastante mais lento que o Or1ksim (ver a secc¸˜ao 2.2.1), mas apesar dessa desvantagem disponibiliza um ficheiro que permite visualizar o estado de todos os sinais dentro do SoC em todos os instantes da simulac¸˜ao, permitindo assim encontrar erros na arquitectura dehardware do SoC. Como ´e efectuada uma convers˜ao a partir dos ficheiros descritivos do SoC, estes testes s˜ao efectuados num sistema idˆentico ao que ser´a fabricado, se n˜ao tivermos em conta a existˆencia de outros estados nos sinais.
Figura 2.7:Diagrama do simulador Verilator.
2.2.3 Icarus Verilog
O Icarus Verilog [19], conhecido por apenas Icarus, ´e uma ferramenta de simulac¸˜ao e de s´ıntese de Verilog. Compila o c´odigo fonte em Verilog na norma(IEEE-1364) e executa a simulac¸˜ao. Como se pode perceber pela figura 2.8, tal como o Verilator (ver a secc¸˜ao 2.2.2), tamb´em necessita de um testbench, mas escrito em Verilog. O Icarus ´e um simulador de m´ultiplos valores, ou seja al´em dos dois valores l´ogicos ’0’ e ’1’ tamb´em simula os estados de alta impedˆancia, indefinido, conflito, etc. ´E um simulador mais pr´oximo da realidade, completamente open source e gratuito que corre num simples computador pessoal.
Tal como o Verilator, o Icarus tamb´em disponibiliza o ficheiro com as formas de onda dos sinais, mas
´e muito mais lento a simular que o Verilator. A principal raz˜ao de ser mais lento tem a ver com o facto de o Icarus ter um motor (programavvp) que interpreta um script com a descric¸˜ao do m´odulo a testar e do seu testbench, produzido por compilac¸˜ao (programaiverilog). Em contraste, o Verilator produz um programa em C++ compilado que executa muito mais rapidamente. O facto de o Icarus suportar m´ultiplos valores l´ogicos tamb´em contribui para o fazer mais lento que o Verilator.
2.2.4 Placa com FPGA
As FPGA’s s˜ao dispositivos semicondutores baseados numa matriz configur´avel de blocos l´ogicos [7, 8, 20]. As FPGA’s podem ser reprogram´aveis ap´os a fabricac¸˜ao para requisitos e funcionalidades distintas.
Permite programar blocos funcionais e recursos de interligac¸˜ao, criando hardware que pode adaptar-se a novas normas, mesmo depois deste estar aplicado e instalado no local do cliente.
O primeiro dispositivo l´ogico program´avel foi a mem´oria PROM (Programmable Read Only Memory), podendo ser programada tanto na fabricac¸˜ao como pelo utilizador, de onde evoluiu a FPGA. Em 1985 a Xilinx desenvolve o primeiro chip em que ´e poss´ıvel programar os blocos de l´ogica bem como a interligac¸˜ao entre elas. Ainda em 1985 foi proposta a ideia de criar um novochipque utilizava uma nova tecnologia de matrizes de blocos program´aveis porsoftware. A experiˆencia tinha dois objectivos: deter-
Figura 2.8:Diagrama do simulador Icarus.
minar uma forma de interligar os planos de matrizes e desenvolver um compilador capaz de programar func¸˜oes para estechip.
Como foi descrito em cima, e como pode ser visto na figura 2.9, o sintetizador ´e utilizado como um compilador que converte a descric¸˜ao dehardwarenum ficheiro de programac¸˜ao para uma determinada FPGA. Para se programar a FPGA ´e utilizado um software disponibilizado pela marca. Assim que
´e programado, ohardware inicia logo o funcionamento. Com uma FPGA o hardwareque estamos a testar ´e igual ao projectado, n˜ao existindo qualquer tipo de diferenc¸a. Comparando com os sistemas de simulac¸˜ao descritos em cima, or1ksim (ver a secc¸˜ao 2.2.1), Verilator (ver a secc¸˜ao 2.2.2) e Icarus (ver a secc¸˜ao 2.2.3), a utilizac¸˜ao uma placa de FPGA ´e mais r´apido e mais realista, mas apresenta um prec¸o elevado. Cada uma destas ferramentas tem a sua vantagem para situac¸˜oes distintas. O or1ksim, por ser bastante r´apido, ´e ideal para a utilizac¸˜ao no desenvolvimento de software; o Verilator, por ter uma representac¸˜ao do hardware e ser relativamente r´apido a simular, ´e o ideal para fazer testes conjuntos de hardware e software; o Icarus, por ter praticamente todo o detalhe dohardware, ´e o ideal para validar ohardwaree revelar problemas que podem n˜ao ter sido detectados com o Verilator; finalmente, a placa de FPGA ´e ideal para validar o SoC, testando o funcionamento dosoftware sobre ohardware respectivo.
Figura 2.9:Diagrama do funcionamento da placa de FPGA.
2.2.5 OpenOCD
O programaOpen On-Chip Degug0ger(OpenOCD) comec¸ou inicialmente por uma tese de mestrado [21], onde se pretendia desenvolver e implementar um debugger para sistemas embebidos, baseado na fam´ılia ARM7 e ARM9. Actualmente existe uma comunidade a trabalhar no OpenOCD [22], suportando novos SoC’s, adaptadores de debug e mem´orias flash program´aveis. O OpenOCD tem como objec- tivo disponibilizar um debugger, um programador de SoC’s e testesboundary-scan para dispositivos embebidos. Para isso, o OpenOCD necessita de adaptadores de debug, sendo que alguns deles j´a se encontram integrados nos kits de desenvolvimento, N˜ao existe uma uniformizac¸˜ao e por essa raz˜ao
´e poss´ıvel encontrar v´arios tipos de adaptadores, destacando-se os com interface Joint Test Action Group(JTAG).
Sem utilizar o OpenOCD, se se quisesse correr umdebugger ligado a um simulador do SoC, tinha que se desenvolver umtestbenchonde era inclu´ıdo um servidor deRemote Serial Protocol(RSP), que estaria ligado SoC em simulac¸˜ao por exemplo, por uma ligac¸˜ao com o protocolo TCP/IP para ligar ao cliente de debug. Se fosse usada uma placa de emulac¸˜ao poderia por exemplo usar-se uma ligac¸˜ao JTAG.
No arranque do OpenOCD ´e necess´ario identificar qual a placa ou simulac¸˜ao alvo (onde executar´a o SoC) e qual ´e a interface que ´e utilizada para comunicar com o alvo. O OpenOCD, depois do arranque, fica dispon´ıvel para ligac¸˜ao ao cliente em trˆes portos, cada um com o seu protocolo espec´ıfico (GDB, Telnet, TCL), como se pode ver na figura 2.10. No caso de se tratarem de placas reais, o OpenOCD pode ligar-se `a placa de interface por Universal Serial Bus (USB), vai processando instruc¸˜oes que vai recebendo do cliente e envia-as por USB para a placa de interface. Esta converte a informac¸˜ao recebida para o protocolo de comunicac¸˜ao (neste caso JTAG), que ´e recebido no m´odulo JTAG do SoC, e enviado para o m´oduloAdvanced Debug System(ADS).
Figura 2.10:Diagrama do OpenOCD.
2.3 Perif ´ericos
Os perif´ericos s˜ao m´odulos com funcionalidades espec´ıficas que s˜ao acrescentadas ao SoC para v´arios fins, e comunicam com o mesmo utilizando um barramento. A comunidade utiliza o barramento Wish- bone (ver a secc¸˜ao 2.1.2), em que os perif´ericos s˜ao conectados ao barramento tal como se pode observar na figura 2.3. Nas subsecc¸˜oes que se seguem descrevem-se os perif´ericos do sistema de- senvolvido.
2.3.1 Boot ROM
A Boot ROM ´e uma pequena mem´oria que tem uma rotina de inicializac¸˜ao do SoC. A Boot ROM pode ser mais ou menos complexa podendo ser por exemplo umaBasic Input Output System (BIOS) de computador ou uma simples rotina que carrega o programa de uma mem´oria secund´aria para a mem´oria principal (RAM).
2.3.2 UART
A UART [23] ´e um m´odulo de comunicac¸˜ao ass´ıncrono, em que o formato dos dados e a velocidade de transmiss˜ao s˜ao configur´aveis. Faz parte de in´umeros circuitos integrados e ´e usada para comunicac¸˜ao com computadores ou dispositivos com porta s´erie. O sub-m´odulo de emiss˜ao recebe bytes de dados e transmite sequencialmente cada bit; o sub-m´odulo de recepc¸˜ao recebe bits sequencialmente e agrupa- os num byte. A comunicac¸˜ao pode ser simples, em que cada m´odulo s´o pode fazer apenas de emissor ou receptor,full duplex, em que ambos os m´odulos podem enviar e receber dados ao mesmo tempo, e half duplex, em que os dois m´odulos podem receber e enviar mas intercaladamente.
Por motivos hist´oricos o sinal de dados encontra-se com o valor l´ogico ’1’ quando n˜ao est´a nenhuma comunicac¸˜ao a decorrer, para mostrar que a linha n˜ao foi danificada. Como se pode ver na figura 2.11, para o caso de envio de 8 bits, o emissor envia inicialmente um bit com valor l´ogico ’0’ para informar o receptor que vai receber um conjunto de bits que pode ser configur´avel entre 5 a 9 bits. Tipica- mente s˜ao usados 8 bits, seguidos opcionalmente de um bit de paridade, que apenas ´e poss´ıvel se na comunicac¸˜ao n˜ao forem enviadas palavras de 9 bits, e por fim o bit de paragem que tem o valor
l´ogico ’1’. Existem v´arios modelos de UART’s sendo que a comunidade optou por utilizar no seu SoC a UART16550. Um parˆametro bastante importante ´e obaud rate, ou seja a taxa de transferˆencia entre o emissor e o receptor, que tˆem de estar de acordo, sen˜ao a transferˆencia n˜ao trabalhar´a correctamente.
Cada m´odulo de UART tem duas linhas: TX (linha de transmiss˜ao) e RX (linha recepc¸˜ao). A ligac¸˜ao entre dois m´odulos ´e cruzada, ou seja liga-se a linha de TX do primeiro ou RX do segundo, e o TX do segundo ao RX do primeiro.
TX
significado espera inicio dados0 dados1 dados2 dados3 dados4 dados5 dados6 dados7 paridade paragem espera
Figura 2.11:Diagrama temporal da UART
2.3.3 GPIO
O m´odulo deGeneral Purpose Input/Output (GPIO) [24], como o nome indica, ´e um banco de sinais de entrada e sa´ıda de uso gen´erico, uma vez que estes pinos n˜ao tˆem uma func¸˜ao espec´ıfica. S˜ao apenas linhas dispon´ıveis e controladas pelo utilizador em tempo de execuc¸˜ao. Na construc¸˜ao de um SoC pode ser ´util ter dispon´ıvel linhas de controlo digital. Os sinais de GPIO podem estar activos ou desactivados, podendo ser programados como entrada ou sa´ıda. Os sinais que est˜ao configurados como entrada permitem apenas leituras, sendo por vezes utilizados para criar interrupc¸˜oes no processador, enquanto que os sinais de sa´ıda permitem leituras (para n˜ao ser necess´ario lembrar o seu estado) e escritas.
Os sinais GPIO tˆem v´arias aplicac¸˜oes t´ıpicas no SoC como por exemplo disponibilizar pinos para portas multifunc¸˜ao, gest˜ao de energia, controlo de codecs de ´audio e placas de v´ıdeo, aplicac¸˜oes em sistemas embebidos para comunicac¸˜ao com sensores, LCD’s, sinalizac¸˜ao de estados com LED’s, etc.
Um exemplo pr´atico de utilizac¸˜ao de pinos GPIO ´e a forma como alguns computadores port´ateis da ACER que usam o GPIO0 para ligar o amplificar das colunas internas, em que o chip Realtek ALC260 tem dispon´ıvel 8 pinos de GPIO que n˜ao s˜ao utilizados por omiss˜ao.
2.3.4 Interface FIFO
Foi desenvolvida uma interface FIFO destinada a interligar assincronamente um m´odulo ao SoC com comunicac¸˜ao paralela de 32 bits por palavra, pretendendo-se que, com esta interface, a comunicac¸˜ao seja r´apida entre os dois m´odulos. Para uma comunicac¸˜ao paralela e ass´ıncrona ´e utilizada uma mem´oria do tipo FIFO para cada sentido, ou seja uma FIFO para o SoC escrever e o m´odulo ler e outra em sentido oposto. Estas FIFO’s ligam-se `a interface Wishbone (ver a secc¸˜ao 2.1.2), e permitem uma velocidade de comunicac¸˜ao elevada. Para al´em disso ´e poss´ıvel ligar a FIFO de recepc¸˜ao ao sistema de interrupc¸˜oes, permitindo assim que uma sub-rotina de interrupc¸˜ao possibilite que a resposta do processador seja ainda mais r´apida e que se possa poupar energia.
2.3.5 I2C
O I2C [25, 26] ´e um barramento desenvolvido pela Philips Semicondutors, agora conhecida como NXP Semicondutors. O I2C ´e um barramento s´erie, s´ıncrono, multi-mestre e multi-escravo, desenvolvido para conectar perif´ericos de baixa velocidade a computadores, sistemas embebidos e a telefones celulares.
Este barramento utiliza apenas duas linhas de comunicac¸˜ao:Serial Data(SDA) para o envio de dados eSerial Clock(SCL) como sinal de rel´ogio controlado pelo o mestre, sendo estas duas linhas de dreno aberto. O I2C define um tipo simples de comunicac¸˜ao entre mestre e escravo, lendo dados do escravo ou escrevendo dados para o escravo. A comunicac¸˜ao comec¸a sempre por um sinal de comec¸o (START) e acaba num sinal de paragem (STOP). Todos os escravos tˆem um enderec¸o de identificac¸˜ao, que ´e utilizado para diferenciar com qual dos escravos o mestre quer comunicar.
Desde Outubro de 2006 que este barramento n˜ao necessita de licenciamento para ser utilizado, tendo cada vez mais utilizac¸˜oes pr´aticas como acessos a pequenas mem´orias de sistemas embebi- dos, comunicac¸˜ao com conversores de digital para anal´ogico e anal´ogico para digital, ou controlo de pequenos monitores como os dos telem´oveis.
2.3.6 SPI
O SPI [27] ´e um barramento s´erie, s´ıncrono, que permite apenas um ´unico mestre e opera em full- duplex, ou seja, permite receber e enviar dados ao mesmo tempo. O barramento utiliza pelo menos 4 sinais se s´o houver um escravo. Se houver mais necessita de mais um sinal para cada escravo que se encontre ligado ao barramento.
Utiliza uma linha de rel´ogio (Serial Clock (SCLK)), tem duas linhas para dados, uma que envia do mestre para o escravo (Master Out Slave In(MOSI)) e outra que envia dados do escravo para o mestre (Master In Slave Out (MISO)). Estas trˆes linhas s˜ao comuns entre os escravos. Por ´ultimo, as linhas que seleccionam qual escravo se pretende comunicar (Slave Select (SS)) s˜ao uma por escravo. Esta linha ´eactive low significa que o escravo s´o se encontra seleccionado quando esta linha se encontra com valor l´ogico ’0’. Este barramento ´e utilizado para pequenas distˆancias, onde ´e preciso uma elevada taxa de transferˆencia de dados, como por exemplo em sistemas embebidos, sensores, LCDs e cart˜oes SD [28].
Cap´ıtulo 3
Interface SPI
O nossoSystem on Chip(SoC) [27] tem dispon´ıvel uma mem´oria principal vol´atil, ou seja sempre que a fonte de alimentac¸˜ao ´e desligada a mem´oria perde a informac¸˜ao contida nela. Ent˜ao ´e necess´ario ter dispon´ıvel no SoC uma outra mem´oria que n˜ao seja vol´atil como um cart˜ao SD, ou uma EEPROM, para se guardar o programa principal, que posteriormente ser´a carregado para a mem´oria principal sempre que o SoC seja inicializado ou seja alimentado. Optou-se pela utilizac¸˜ao de um cart˜ao SD por permitir uma f´acil substituic¸˜ao em qualquer local (ver figura 3.1). Como t´ınhamos em mente aplicac¸˜oes em locais de dif´ıcil acesso, ´e importante facilitar a sua substituic¸˜ao. Como se pode ver na tabela 3.1, o cart˜ao SD tem uma interface SPI.
Figura 3.1:Cart˜ao SD com interface SDI
Pinos SD Nome(SD) Nome (SPI) Direcc¸˜ao Descric¸˜ao
1 CS SS input Selecciona o cart˜ao
2 DI MOSI input Entrada de dados
3 VSS – – Tens˜ao de alimentac¸˜ao(massa)
4 VDD – – Tens˜ao de alimentac¸˜ao
5 SCLK SCLK input Rel´ogio do sistema
6 VSS – – Tens˜ao de alimentac¸˜ao(massa)
7 DO MISO output Sa´ıda de dados
8 RSV – – Reservado
9 RSV – – Reservado
Tabela 3.1:Pinos do cart˜ao SD com interface SPI
Como foi dito na secc¸˜ao 2.3.6, o SPI ´e um barramento de comunicac¸˜ao utilizado para casos onde ´e necess´ario uma comunicac¸˜ao com velocidade de transferˆencia elevada. Como neste caso se pretende uma inicializac¸˜ao r´apida, ´e utilizado o barramento SPI.
O barramento ´e constitu´ıdo por trˆes sinais de comunicac¸˜ao e mais um sinal por cada escravo que esteja ligado ao mestre, como se pode ver na figura 3.2. Na figura podem ver-se trˆes escravos, os trˆes sinais de comunicac¸˜ao e os trˆes sinais de selecc¸˜ao de cada escravo. Os sinais de comunicac¸˜ao (SCLK, MOSI e MISO) est˜ao ligados em paralelo a todos os escravos. Cada escravo tem o seu sinal SS independente. Um escravo est´a seleccionado quando o seu sinal SS tem valor l´ogico de ’0’; apenas o escravo que est´a seleccionado lˆe e/ou escreve no barramento. Como se trata de barramentofull-duplex, est´a dispon´ıvel uma linha de escrita no escravo MOSI e outra de leitura do escravo MISO. O sinal SCLK
´e o sinal de rel´ogio com os quais os dados de leitura ou escrita est˜ao sincronizados. Para se efectuar uma comunicac¸˜ao o mestre SPI selecciona o escravo com o qual pretende comunicar e envia uma ou mais palavras de 8 bits no sinal MOSI. Posteriormente o mestre necessita de transmitir mais impulsos de rel´ogio para o escravo, para este poder transmitir os dados pedidos pelo mestre na linha MISO.
Figura 3.2:Sistema de comunicac¸˜ao SPI com 1 mestre e 3 escravos
3.1 Mestre SPI
A comunidade OpenRISC tinha dispon´ıvel um n´ucleo de mestre SPI com interface Wishbone para ligac¸˜ao ao SoC. Por´em, este n´ucleo apenas realizava correctamente escritas para o escravo, n˜ao efectuando qualquer leitura de dados do escravo. Sendo uma parte indispens´avel para o objectivo do projecto que, como foi dito anteriormente, o n´ucleo de SPI efectuasse leituras da mem´oria de cart˜ao SD para carregamento do programa na mem´oria principal, esta parte foi desenvolvida no ˆambito deste trabalho.
Na figura 3.3 pode se ver o fluxo de dados dentro do n´ucleo mestre de SPI. Quando se pretende enviar uma palavra para o escravo esta ´e recebida pelo n´ucleo vindo da interface Wishbone e ´e guar- dada na FIFO interna, onde s˜ao guardados os dados para se enviar para o escravo at´e 4 palavras. Na figura 3.3 esta FIFO est´a identificada como FIFO IN. Quando o sub-m´odulo que faz a serializac¸˜ao se
encontra parado e detecta que tem dispon´ıvel uma palavra para enviar na FIFO, vai buscar a palavra que est´a guardada e comec¸a a gerar impulsos de rel´ogio, ao mesmo tempo que serializa a palavra e a envia bit a bit para o escravo pelo sinal MOSI.
Quando se pretende receber dados do escravo, o processador tem de identificar o enderec¸o que pretende ler. De seguida o sub-m´odulo de desserializac¸˜ao recebe a informac¸˜ao de leitura do proces- sador, se a FIFO, identificada na figura com o nome de FIFO OUT, que recebe as palavras vindas do escravo n˜ao estiver cheia. O mestre comec¸a a gerar impulsos de rel´ogio para que o escravo envie os dados. O m´odulo recebe bit a bit a palavra do escravo no sinal MISO. Quando receber a palavra toda deixa de gerar impulsos de rel´ogio e guarda a palavra na FIFO. Em seguida a palavra ser´a enviada da FIFO para o processador pela interface Wishbone. Visto que se trata de uma interfacefull-duplex, quando se encontra a enviar dados para o escravo, o mestre tamb´em pode ler a linha MISO. No caso destes dados serem lixo ´e necess´ario ter em atenc¸˜ao que os dados tˆem de ser removidos da FIFO quando se for efectuar a primeira leitura.
Figura 3.3:Fluxo dos dados no n´ucleo mestre SPI
Na tabela 3.2 temos todos os sinais do n´ucleo mestre de SPI com uma pequena descric¸˜ao. Os primeiros 10 sinais correspondem `a interface Wishbone que ´e ligada ao multiplexer Wishbone de dados,
`a semelhanc¸a dos n´ucleos de UART e GPIO como se pode ver na figura 2.3. Os ´ultimos quatros sinais correspondem ao barramento SPI e s˜ao ligados ao escravo.
A tabela 3.3 cont´em uma lista dos registos do mestre SPI com uma pequena descric¸˜ao de cada registo e do seu enderec¸o local.
O n´ucleo mestre de SPI disponibiliza o modo de escrita que j´a se encontrava funcional, ficando com este trabalho a disponibilizar tamb´em o modo de leitura de dados que n˜ao se encontrava totalmente funcional.
Interface Nome Direcc¸˜ao Descric¸˜ao
Wishbone
clk i input Rel´ogio recebido pelo Wishbone.
rst i input Reinicia o n´ucleo quando se encontra no valor logic ’1’.
cyc i input Validac¸˜ao da informac¸˜ao no barramento stb i input Validac¸˜ao dos dados transmitidos
adr i input Enderec¸o do registo onde se pretende ler ou escrever no n´ucleo.
we i input Bit de selecc¸˜ao de escrita.
dat i input Recepc¸˜ao de dados pelo processador.
dat o output Envio de dados do processador.
ack o output Bit que informa o processador da recepc¸˜ao dos dados pelo n´ucleo.
inta o output Bit de interrupc¸˜ao.
SPI
sck o output Rel´ogio do protocolo de comunicac¸˜ao SPI.
ss o output Faz a selecc¸˜ao do escravo que se pretende ler ou escrever.
mosi o output Envio de dados para o escravo (Master Out Slave In).
miso i input Recepc¸˜ao de dados do escravo (Master Out Slave In).
Tabela 3.2:Tabela de sinais da interface SPI mestre
Nome Leitura/Escrita Descric¸˜ao Enderec¸o
Registo de controlo Leitura e Escrita Permite ler o estado no n´ucleo e altera o n´ucleo para modo mestre ou n˜ao. Por default est´a em modo Master
0X00
Tipo de leitura Escrita Selecciona o tipo de leitura (Simples, Burst) 0X01 Registo de estado Leitura Disponibiliza v´arias informac¸˜oes do estado
do n´ucleo 0X01
Leitura de dados Leitura Leitura dos dados recebidos pelo SPI 0X02 Escrita de dados Escrita Escrita dos dados a enviar pelo SPI 0X02 Extens˜ao registo de
controlo Leitura e Escrita Complementa a possibilidade de
configurac¸˜oes existente no enderec¸o 0X00 0X03 Selecc¸˜ao do escravo Leitura e Escrita selecciona o escravo que se pretende escre-
ver ou ler 0X04
Tabela 3.3: Tabela de registos da interface SPI master
No modo de leitura existente, a que vou chamar de simples, era poss´ıvel apenas para ler uma
´unica palavra de 8 bits. Quando se pretendia efectuar uma leitura de v´arios enderec¸os consecutivos, com este modo de leitura perde-se bastante tempo porque o processador tem de ficar `a espera que o mestre pec¸a uma palavra ao escravo e que este responda a cada pedido de leitura. Se tivermos em conta que para carregar um programa ´e necess´ario ler m´ultiplas palavras seguidas do cart˜ao SD, ent˜ao torna-se ´obvia a limitac¸˜ao deste modo de leitura.
Para diminuir o tempo em que o processador est´a `a espera da resposta do n´ucleo, a soluc¸˜ao encon- trada foi a de existirem dois modos de leitura, o modo simples, como descrito acima, e um novo modo de leitura emburst. Assim, quando se efectua uma leitura ´e necess´ario identificar o tipo de leitura, o que ´e feito no registo com o enderec¸o 0x01, como se pode ver na tabela 3.3. Se naquele enderec¸o es- crevemos a palavra 0x02 ent˜ao pretendemos realizar uma leitura simples, se escrevermos 0x01 ent˜ao pretendemos realizar uma leitura emburst. A principal diferenc¸a entre os dois modos de leitura ´e que na leitura simples o n´ucleo pede uma palavra de dados ao escravo ap´os cada pedido do processador, enquanto na leitura embursto n´ucleo faz pedidos sucessivos de palavras de dados ao escravo, at´e a
FIFO de sa´ıda ficar cheia. Ou seja, o processador n˜ao precisa de pedir os dados palavra a palavra.
Este tipo de leitura s´o ´e poss´ıvel quando s˜ao leituras de enderec¸os sucessivos, se pretendermos ler 250 enderec¸os consecutivos temos um ganho de 0.23705 milissegundos, corresponde a aproximadamente metade do tempo que levaria uma leitura simples.
Como se pode ver, as figuras 3.4 e 3.5 s˜ao ambos excertos retirados da leitura das 250 posic¸˜oes de mem´oria de SPI. Tamb´em em ambas as figuras, os momentos em que as palavras de dados s˜ao envias do n´ucleo mestre de SPI para o processador est´a assinalado com linhas verticais cor de rosa, sendo a primeira um burst e a segunda uma leitura simples. Como se pode ver a leitura em burst envia quatro palavras no mesmo tempo que a leitura simples envia envia duas. Esta melhoria deve- se principalmente ao facto de o processador n˜ao necessitar de informar o n´ucleo mestre de SPI que pretende ler mais um enderec¸o de mem´oria, e tamb´em ao facto de a palavra j´a estar preparada, sendo disponibilizada automaticamente. Tamb´em pode ser visto na pen´ultima onda da figura 3.4 o estado da FIFO de leitura: est´a cheia quando este sinal ´e ”1”ou n˜ao se for ”0”. A FIFO est´a cheia a maior parte do tempo, excepto quando ´e feita uma leitura pelo processador e quando isto acontece ´e logo compensada com uma leitura de dados ao n´ucleo escravo SPI.
Figura 3.4:Excerto de leituraburst
Figura 3.5:Excerto de leitura em simples
3.2 Escravo SPI
O n´ucleo escravo SPI foi desenvolvido de raiz, por na altura n˜ao existir nenhum j´a desenvolvido pela co- munidade. O n´ucleo est´a estruturado como se pode ver na figura 3.6. O m´odulo com o nome SPI fe tem
como objectivo serializar e desserializar os dados enviados ou recebidos do mestre, respectivamente.
Os dados passam para o m´odulo SPI protocol que trata a informac¸˜ao dos dados recebidos com uma m´aquina de estados, separando enderec¸os e dados de modo a ler ou escrever em registos arbitr´arios do escravo tal como se de uma mem´oria se tratasse.
Figura 3.6:Estrutura e fluxo de dados no n´ucleo SPI escravo
Na tabela 3.4 listam-se os sinais de entrada e sa´ıda do n´ucleo escravo SPI com uma pequena descric¸˜ao.
Interface Nome Direcc¸˜ao Descric¸˜ao
SPI
clk input Clock, Recebido pelo Wishbone.
rst input Reset, reinicia o n´ucleo quando se encontra no valor l´ogico ”1”.
sclk input Clock do protocolo de comunicac¸˜ao SPI.
ss input selecciona se ´e o escravo pretendido
mosi input recepc¸˜ao de dados do master (masterOut SlaveIn).
miso output envio de dados para o master (masterOut SlaveIn).
Registo
data in input linha que recebe os dados lidos na mem´oria data out output linha que envia os dados a guarda na mem´oria
address output linha que envia o enderec¸o de mem´oria que se pretende ler ou escrever.
we output linha que indica se se trata de uma leitura ou escrita para a mem´oria
Tabela 3.4:Tabela de sinais da interface do n´ucleo SPI escravo.
O n´ucleo escravo tem dispon´ıvel um modo de leitura e outro de escrita. A primeira palavra enviada para o escravo ´e constitu´ıda pelo enderec¸o e pela informac¸˜ao se se pretende escrever ou ler. A l´ogica de interpretac¸˜ao est´a implementada no m´odulo spi protocol, isolando o bit mais significativo. Se este tiver um valor l´ogico ’1’ indica que se pretende efectuar uma leitura, caso contr´ario, ou seja, se tiver o
valor l´ogico ’0’, indica que se pretende efectuar uma escrita. O restante da primeira palavra corresponde ao enderec¸o onde se pretende ler ou escrever. Caso seja uma leitura, o mesmo m´odulo efectua a leitura com o enderec¸o recebido na mem´oria ou banco de registos. A palavra lida ´e depois enviada para o m´odulo spi fe que a serializa e envia pelo sinal MISO. Se o processo for de escrita, o m´odulo spi fe desserializa a palavra que ´e recebida no sinal MOSI depois do enderec¸o, e envia-a para o m´odulo spi protocol, o qual a escreve na mem´oria ou banco de registos no enderec¸o registado previamente.
3.3 Diagramas temporais
Em seguida apresentam-se diagramas temporais com uma breve explicac¸˜ao do que ocorre em cada diagrama.
3.3.1 Selecc¸ ˜ao de escravos
Na figura 3.7 ilustra-se o processo de selecc¸˜ao de escravos. Assume-se que est˜ao ligados dois escra- vos ao mestre de SPI. Por essa raz˜ao existem dois sinais de SS cada um ligado apenas a um escravo.
Como foi dito acima, o sinal de SS ´e activo em baixo, ou seja, o escravo est´a seleccionado quando o seu sinal SS tem o valor l´ogico ’0’. No primeiro flanco positivo do sinal SCLK nenhum dos escravos est´a seleccionado. O escravo 1 ´e seleccionado no primeiro flanco negativo e assim se mant´em at´e ao segundo flanco negativo. O segundo escravo ´e seleccionado no terceiro flanco negativo e desse- leccionado no quarto flanco negativo. Apenas o segundo e o quarto flanco positivo tˆem um escravo seleccionado, o primeiro e o segundo escravo, correspondentemente.
SCLK SS1 SS2 MOSI MISO
Figura 3.7:Diagrama temporal da selecc¸˜ao do escravo
3.3.2 Transfer ˆencia de Dados
Os dados transmitidos tanto pelo mestre como pelo escravo s˜ao lidos nos flancos positivo.
Envio de dados pelo mestre
O envio de dados do mestre para o escravo ´e feito pelo sinal MOSI, como se pode ver na figura 3.8. O escravo s´o guarda os dados que lhe forem enviados se estiver seleccionado, o que s´o acontece ap´os o segundo flanco positivo. Ap´os o escravo estar seleccionado os dados s˜ao lidos no flanco positivo do sinal de SCLK. Nesta figura, por exemplo, as palavras s˜ao de 6 bits. A palavra recebida pelo escravo ´e a palavra 110100 em base bin´aria.
SCLK SS MOSI MISO
Figura 3.8:Diagrama temporal do envio de dados pelo mestre
Envio de dados pelo escravo
Para o escravo enviar dados, o mestre necessita de criar o sinal de rel´ogio SCLK e o escravo necessita de usar o sinal MISO para enviar os dados enquanto se encontra seleccionado. Tal como no envio de dados do mestre para o escravo, no envio de dados do escravo para o mestre os dados s˜ao lidos nos flancos positivos do sinal de rel´ogio gerado pelo mestre. No exemplo da figura 3.9, a palavra envida pelo escravo ´e de 6 bits, e ´e a palavra 010110 em base bin´aria.
SCLK SS MOSI MISO
Figura 3.9:Diagrama temporal do envio de dados pelo escravo
Cap´ıtulo 4
I2C
O nossoSystem on Chip(SoC) utiliza uma mem´oria de pequenas dimens˜oes, n˜ao vol´atil, que permite guardar alguns dados relevantes em caso de algum problema com o SoC, como por exemplo, a falta de energia. Esta mem´oria utiliza uma interface I2C.
O barramento I2C [25] utiliza apenas dois sinais para comunicac¸˜ao. Sendo um barramento s´ıncrono, uma das linhas ´e o sinal de rel´ogio SCL e a outra linha ´e o sinal de dados SDA. Apesar de ser um barramento relativamente lento comparado com o SPI (cap´ıtulo 3), ´e um barramento bastante utilizado pela sua simplicidade e facilidade de adicionar mais perif´ericos aos j´a existentes, como se pode ver na figura 4.1. Para adicionar um perif´erico, ´e necess´ario apenas ligar os dois sinais do barramento ao perif´erico. Em vez de utilizar, como na interface SPI, uma linha para seleccionar o perif´erico, todos os perif´ericos tˆem o seu enderec¸o de sete bits. Alguns perif´ericos possibilitam a alterac¸˜ao dos bits menos significativos, o que permite, por exemplo, ter uns quantos perif´ericos iguais. O mestre envia um enderec¸o de oito bits, sendo os sete bits mais significativos os que definem o escravo que se pretende seleccionar e o bit menos significativo ´e utilizado para informar o escravo se o mestre pretende escrever (valor l´ogico ’0’), ou ler (valor l´ogico ’1’). Como s´o existem dois sinais de comunicac¸˜ao, o barramento tem uma comunicac¸˜ao muito controlada, sendo necess´aria a utilizac¸˜ao de v´arias sinalizac¸˜oes, enviadas em momentos espec´ıficos da comunicac¸˜ao para serem interpretados tanto pelo escravo como pelo mestre.
Este cap´ıtulo est´a organizado do seguinte modo. Na secc¸˜ao 4.1 explica-se a estrutura do n´ucleo mestre de I2C e na secc¸˜ao 4.2 explica-se a estrutura do escravo. Na secc¸˜ao 4.3 ser˜ao explicados as v´arias sinalizac¸˜oes existentes.
A operac¸˜ao do protocolo I2C pode resumir-se do seguinte modo. Para comec¸ar a comunicar o mestre envia uma sinalizac¸˜ao deStart bit(secc¸˜ao 4.3.1), seguido de 8 bits correspondente ao enderec¸o do escravo com que pretende comunicar. De seguida o escravo responde com uma sinalizac¸˜ao de ACK (secc¸˜ao 4.3.5) a informar que recebeu a convocat´oria. No caso de ser uma leitura o mestre cria impulsos de rel´ogio para que o escravo lhe envie os dados, respondendo depois com um ACK. Neste processo o escravo vai enviando dados para o mestre enquanto este responder com ACK. Quando responder com um Negative-Acknowledge (NACK) 4.3.6 o escravo p´ara de enviar dados e o mestre termina a comunicac¸˜ao com a sinalizac¸˜ao deStop bit(secc¸˜ao 4.3.2). No caso de ser uma escrita o mestre envia
