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.

(a) Diagrama temporal do ciclo de leitura simples

Clock

(b) Diagrama temporal do ciclo de escrita simples

Clock icfsm_burst biu_dat_i

biu_adr_i 0000D650 0000D654 0000D658 0000D65C

biu_cyc_i

(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 em bare-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 or1ksim-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 imporbas-tantes 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.