Particionamento

Um SoC ´e definido pelos seus diferentes n´ucleos ou cores e estes interagem para a realiza¸c˜ao de tarefas espec´ıficas. Para obter o funcionamento correto, o projetista do SoC precisa definir o conjunto de componentes que ser´a utilizado na implementa¸c˜ao e distribuir as tarefas que devem ser executadas pelo SoC entre esses componentes. O conjunto de componentes selecionados para integrar o SoC assim com a opera¸c˜ao de sele¸c˜ao s˜ao chamados de aloca¸c˜ao e o resultado da distribui¸c˜ao de tarefas ´e chamada de parti¸c˜ao mas a opera¸c˜ao de distribui¸c˜ao ´e chamada de particionamento. A aloca¸c˜ao e o particionamento devem ser efetuados de modo que a imple- menta¸c˜ao satisfa¸ca restri¸c˜oes do projeto, tais como, custo, desempenho, tamanho e consumo de energia (GAJSKI et al., 1994). Existem duas t´ecnicas bem distintas de particionamento, denominadas de particionamento estrutural e particionamento funcional.

1.1.4.1 Particionamento estrutural

No particionamento estrutural, inicialmente ´e definida a estrutura de hardware do projeto, compreendendo componentes de hardware e suas conex˜oes. Os componentes de hardware podem ser simples portas l´ogicas ou unidades complexas de c´alculo e microprocessadores. Em seguida, a estrutura ´e particionada. O particionamento agrupa os componentes em grupos onde cada um representa um componente macro do sistema. O particionamento estrutural possui a vantagem de estimar diretamente o tamanho da implementa¸c˜ao final do CI assim como a quantidade de pinos. O tamanho ´e estimado pela soma dos tamanhos dos componentes de cada grupo e o n´umero de pinos ´e estimado pelo n´umero de conex˜oes entre um grupo e outro (GAJSKI et al.,

1994). As trˆes maiores desvantagens do particionamento estrutural s˜ao:

• Dif´ıcil balan¸co entre tamanho e desempenho - Como a defini¸c˜ao da estrutura ´e feita antes do particionamento, esta segunda etapa pode acabar anulando a primeira. No caso do projetista optar por uma estrutura de hardware m´ınima, na etapa de particionamento tarefas iguais e sequenciais podem ser atribu´ıdas a grupos diferentes, gerando uma perda de desempenho. No caso contr´ario, onde o projetista opta por utilizar mais hardware e na etapa de particionamento o m´aximo de tarefas iguais e sequenciais ´e atribu´ıda ao mesmo grupo, isto gera um desperd´ıcio de ´area.

• Quantidade de componentes - Os algoritmos utilizados para particionamento n˜ao est˜ao evoluindo na mesma velocidade que os sistemas est˜ao crescendo e a quantidade de componentes em um ´unico CI aumenta. Sistemas muito grandes tendem a um particio- namento ruim.

1.1 Sistemas Embutidos 19

• Solu¸c˜oes apenas de hardware - O particionamento estrutural ´e limitado apenas `a parte de hardware do projeto e n˜ao ao funcionamento do sistema por completo. Partes do sistema que podem ser implementadas em software, assim como o software que governa o funcionamento do sistema, s˜ao ignorados.

`

A medida que os projetos de SoCs se tornam mais complexos e os CIs acomodam cada vez mais transistores, as desvantagens do particionamento estrutural tornam-se mais evidentes

(GAJSKI et al., 1994).

1.1.4.2 Particionamento funcional

No particionamento funcional, inicialmente o sistema ´e dividido em fun¸c˜oes indivis´ıveis, chama- das de objetos funcionais. Em seguida ´e feito o particionamento que consiste em implementar cada objeto funcional atrav´es de hardware ou software. As trˆes maiores vantagens do particio- namento funcional em rela¸c˜ao ao particionamento estrutural s˜ao:

• Balan¸co entre tamanho e desempenho - Na etapa de implementa¸c˜ao estrutural, sub- sequente ao particionamento funcional, a utiliza¸c˜ao dos componentes pode ser otimizada ao m´aximo, maximizando o desempenho e minimizando a ´area ocupada.

• Quantidade de componentes - Menor quantidade de componentes a ser particionada, j´a que a quantidade de objetos funcionais ´e menor do que a quantidade objetos em n´ıvel de hardware. Com menos objetos, o desempenho dos algoritmos de particionamento ´e melhor e o projetista pode tomar decis˜oes com mais facilidade.

• Solu¸c˜ao hardware/software - A maior vantagem do particionamento funcional ´e que ele permite um particionamento de hardware e software. Isso ´e poss´ıvel porque os objetos particionados s˜ao funcionais e n˜ao estruturais. Objetos funcionais podem ser implemen- tados em um processador na forma de um conjunto de instru¸c˜oes ou como componentes de hardware. Como a maioria dos sistemas baseados em SoCs possuem partes de hard- ware e software, a capacidade de particionar entre estas duas plataformas ´e indispens´avel para qualquer sistema de particionamento.

Como visto anteriormente, o projeto baseado em plataforma ´e composto de bibliotecas de hardware, na forma de IPs, e de softwares. Estas duas partes da plataforma, respectiva- mente, formam a plataforma de hardware e a plataforma de software. Estas duas plataformas podem ser implementadas separadamente nas ferramentas de projeto mais modernas, como EDK (Embedded Development Kit) da Xilinx.

1.1 Sistemas Embutidos 20

1.1.5

Plataforma de hardware

Reutiliza¸c˜ao ´e a palavra chave para reduzir custos nos projetos de SoCs e dispositivos m´oveis em geral. Acredita-se que estes dispositivos representar˜ao a maioria dos dispositivos eletrˆonicos em breve. Como os projetistas de SoCs implementam cada vez mais fun¸c˜oes em software, ´e necess´aria uma arquitetura m´ınima de hardware que possa ser facilmente alterada e reutilizada por diferentes aplica¸c˜oes. Esta arquitetura m´ınima de hardware ´e chamada de plataforma de hardware (KEUTZER et al., 2000).

As restri¸c˜oes impostas pela aplica¸c˜ao, em termos de desempenho influenciam na defini- ¸c˜ao da plataforma de hardware. Para implementar um conjunto de funcionalidades, ´e necess´ario um microprocessador com um conjunto m´ınimo de microinstru¸c˜oes e uma mem´oria com uma quantidade m´ınima de bytes (TANENBAUM, 2005). Como cada projeto ´e caracterizado por um conjunto diferente de funcionalidades, as restri¸c˜oes de cada projeto definem os IPs, que em conjunto com o microprocessador, ser˜ao respons´aveis por tarefas espec´ıficas e garantir˜ao o de- sempenho desejado. Al´em das restri¸c˜oes impostas pela aplica¸c˜ao tamb´em existem as pr´oprias restri¸c˜oes de hardware em termos de custo, consumo de energia, ´area e outros. A intercess˜ao entre as restri¸c˜oes do dom´ınios da aplica¸c˜ao e as restri¸c˜oes do dom´ınio de hardware definem a plataforma de hardware que ser´a utilizada no produto final (KEUTZER et al., 2000).

1.1.6

Plataforma de software

A plataforma de hardware por si s´o n˜ao ´e suficiente para atingir o n´ıvel de reutiliza¸c˜ao de software desejado. Para ser reaproveit´avel, a plataforma de hardware precisa ser abstrata para o software em execu¸c˜ao. O software precisa “enxergar”uma interface de alto-n´ıvel acima da camada de hardware. Esta interface de alto n´ıvel ´e chamada de API (Application Program Interface). A API constitui a plataforma de software que encapsula a plataforma de hardware possibilitando a abstra¸c˜ao desejada dos componentes de hardware.

A camada de software ´e constitu´ıda por drivers que controlam os dispositivos de E/S, por um protocolo de comunica¸c˜ao que controla a comunica¸c˜ao entre os componentes do SoC e um sistema operacional de tempo real, comumente chamado de RTOS (Real Time Operating System). Algumas literaturas denominam a plataforma de software como RTOS, incluindo os drivers de E/S e o protocolo de comunica¸c˜ao. A Figura 6 mostra a estrutura da camada de software e as demais camadas de um projeto baseado em plataforma (KEUTZER et al., 2000).

Um n´ıvel acima da plataforma de software est´a o software programado para executar as funcionalidades do projeto, representando o n´ıvel mais alto de abstra¸c˜ao. Atualiza¸c˜oes do

1.2 Redes Embutidas 21

Interface de

Sa´ıda Interface deEntrada

Plataforma de Hardware Plataforma de Software Software de Aplica¸c˜ao R T O S P ro to co lo d e C om u n ic a¸c ˜ao BIOS Drivers Plataforma de software

Figura 6: Camadas de um projeto baseado em plataforma

projeto podem ser feitas diretamente na camada mais alta, reduzindo consideravelmente o custo e tempo de lan¸camento de um novo produto no mercado. No entanto, ainda existe o entrave da compatibilidade. Os programas de alto n´ıvel devem ser desenvolvidos para uma plataforma de software ou um RTOS espec´ıfico. Para maximizar a capacidade de reutiliza¸c˜ao de projetos ´e necess´aria a padroniza¸c˜ao da plataforma de software. Atualmente cada fabricante desenvolve o seu pr´oprio RTOS ou ent˜ao adota um sistema existente no mercado.

1.2

Redes Embutidas

No ano de 2002 pesquisadores do ITRS (International Technology Roadmap for Semiconduc- tors) fizeram a previs˜ao de que at´e o final da d´ecada, SoCs seriam fabricados com 4 bilh˜oes de transistores na ordem de 50nm cada, operando abaixo de 1V e operando com uma frequˆencia de 10Ghz. Talvez n˜ao cheguemos a tantos transistores em um CI e nem a frequˆencia de 10Ghz at´e o final desta d´ecada, mas os n´umeros atuais j´a representam um desafio no projeto de SoCs. A grande quantidade de conex˜oes dos componentes internos representa um fator limitador de desempenho e gera alto consumo de energia (BENINI; MICHELI, 2002).

Al´em da grande quantidade de conex˜oes internas, existe o problema de sincroniza¸c˜ao, que ser´a muito dif´ıcil, sen˜ao imposs´ıvel, de ser resolvido `a medida que a quantidade de com- ponentes e a frequˆencia de opera¸c˜ao aumentam. Uma poss´ıvel solu¸c˜ao para o problema de sincroniza¸c˜ao consiste em utilizar diferentes sinais de clocks, gerando um sistema globalmente ass´ıncrono e localmente s´ıncrono. Na ausˆencia de uma ´unica frequˆencia de opera¸c˜ao de referˆen- cia, um SoC se transforma em um sistema distribu´ıdo embutido em um ´unico CI. O controle global do sistema se torna mais dif´ıcil porque ´e preciso monitorar cada um dos subsistemas formados. O controle de comunica¸c˜ao entre os m´ultiplos dom´ınios de frequˆencia de opera¸c˜ao pode ser muito custoso e at´e mesmo invi´avel (BENINI; MICHELI, 2002).

1.2 Redes Embutidas 22

A baixa tens˜ao de alimenta¸c˜ao, a grande quantidade de barramentos em diferentes frequˆencias de opera¸c˜ao e o reduzido tamanho dos CIs, pode tornar os dispositivos mais sus- cept´ıveis a interferˆencia eletromagn´etica, crosstalk e a inje¸c˜ao de cargas induzidas (BENINI;

MICHELI, 2002), ocasionando erros na transmiss˜ao de dados. A transmiss˜ao de dados digitais

em tais condi¸c˜oes seria n˜ao determin´ıstica e talvez impratic´avel.

O projeto de SoCs depende fortemente de uma plataforma modular, tanto para soft- ware quanto para hardware. O uso de m´etricas probabil´ısticas, como desempenho e consumo de energia, para a avalia¸c˜ao de projeto, leva a uma mudan¸ca de metodologia no projeto de SoCs. Com base no fato que a comunica¸c˜ao ser´a o maior limitador no projeto de SoCs, uma nova metodologia de comunica¸c˜ao inspirada nas infra-estruturas de redes de computadores foi desenvolvida para os SoCs. Esta nova metodologia aproveita o conhecimento de engenharia consolidado no projeto de grandes redes de computadores e utiliza-o no projeto de SoCs, dando origem `as redes embutidas, ou simplesmente NoCs (Networks-on-Chip).

A arquitetura NoC, al´em de eliminar os problemas de interferˆencia citados anterior- mente, pode ser empregada em SoCs com m´ultiplos processadores, os MPSoCs (PANDE et al., 2005). A tendencia natural ´e que os projetos de SoCs utilizem m´ultiplos processadores, cri- ando um ambiente de computa¸c˜ao paralela dentro de um CI. Para viabilizar a comunica¸c˜ao entre os processadores e os demais dispositivos do CI, ´e desej´avel que a comunica¸c˜ao interna se assemelhe a comunica¸c˜ao de computadores por meio de uma rede de dados. Projetos baseados em arquitetura NoC atendem aos requisitos de comunica¸c˜ao impostos atualmente nos projetos de SoCs e MPSoCs.

Embora a arquitetura NoC esteja baseada na arquitetura de comunica¸c˜ao de computa- dores, um conjunto significativo de restri¸c˜oes separa estas duas arquiteturas. Em rela¸c˜ao ao desempenho, o alto throughput e a baixa latˆencia s˜ao caracter´ısticas desejadas em ambos os dom´ınios. Contudo, na perspectiva de NoCs, a energia dissipada para realizar a comunica- ¸c˜ao pode ser significativa comparada com a energia total do sistema. A ´area utilizada pelos componentes de comunica¸c˜ao ´e ent˜ao uma outra caracter´ıstica importante que deve ser obser- vada durante o projeto. Esta metodologia permite um alto n´ıvel de abstra¸c˜ao do modelo de comunica¸c˜ao (PANDE et al., 2005).

1.2.1

Arquitetura interna

Uma importante caracter´ıstica na metodologia baseada em NoC consiste na separa¸c˜ao entre componentes de comunica¸c˜ao e aqueles de processamento. A comunica¸c˜ao entre os componen-

1.2 Redes Embutidas 23

S S S

S S S

S S S

rni rni rni rni rni rni rni rni rni

m m m m m c d c p c m re c re c d c m d c m p fp c m p

Figura 7: NoC de tipo malha com nove recursos

tes de processamento ´e responsabilidade da plataforma de rede enquanto que os componentes da plataforma de hardware ou de processamento ficam dedicados apenas para a execu¸c˜ao das funcionalidades da aplica¸c˜ao propriamente ditas. Neste contexto, os elementos da plataforma de hardware s˜ao geralmente chamados de recursos. Cada recurso ´e um meio f´ısico onde IPs podem ser implementados, gerando assim um core (ou n´ucleo) da rede. Os componentes da plataforma de rede s˜ao os canais, os switches e as interfaces de rede. Os canais s˜ao barra- mentos por onde os dados trafegam e permitem a interliga¸c˜ao dos switches. Os switches s˜ao respons´aveis pela l´ogica de roteamento e chaveamento da rede. As interfaces de rede ou RNIs (Resource Network Interface) implementam as liga¸c˜oes entre switches e recursos. Cada recurso deve possuir sua pr´opria interface de rede para que possa se comunicar com o restante dos recursos da plataforma de hardware. A Figura 7 apresenta uma estrutura de NoC em malha

(KUMAR et al., 2002) denominada de CLICH´E (Chip-Level Integration of Communicating He-

terogeneous Elements), onde diferentes blocos IPs est˜ao implementados nos recursos e as siglas utilizadas significam: C – mem´oria cache, D – bloco DSP, FP – unidade de ponto flutuante, M – mem´oria, P – processador, Re – bloco reconfigur´avel e RNI – interface de rede.

No caso de uma implementa¸c˜ao em um CI, qualquer IP pode ser implementado em um recurso desde que o recurso disponha de ´area de hardware suficiente. No caso de implementa¸c˜oes em hardware reconfigur´avel, como uma FPGA, a implementa¸c˜ao do IP depender´a dos recursos b´asicos dispon´ıveis na FPGA, como flip-flops e lookup tables. Qualquer recurso dotado de uma interface de rede, que esteja ligada a um switch, pode estabelecer comunica¸c˜ao com qualquer outro recurso da NoC que apresente as mesmas condi¸c˜oes. A interface de rede identifica cada recurso com um endere¸co f´ısico. Qualquer recurso conectado a rede ´e visto como um sistema embutido independente. A rede inteira pode ser considerada como um sistema distribu´ıdo,

1.2 Redes Embutidas 24

onde os componentes da plataforma de rede disponibilizam servi¸cos de comunica¸c˜ao (SOININEN;

HEUSALA, 2003).

A arquitetura do switch depende do esquema de roteamento utilizado na NoC. As duas principais categorias de roteamento s˜ao: determin´ıstica e adaptativa. Algoritmos de roteamento determin´ısticos sempre tra¸cam o mesmo caminho entre um recurso origem e um recurso des- tino. Algoritmos adaptativos utilizam a informa¸c˜ao do trafego nos canais da rede para evitar congestionamento ou falha no envio de mensagens. Em uma NoC com roteamento determi- n´ıstico, os switches s˜ao mais r´apidos e mais compactos. No caso de roteamento adaptativo, o switch precisa de mais ´area de hardware para implementar o processamento necess´ario que permite avaliar as condi¸c˜oes da rede (PANDE et al., 2005). Outro fator de impacto no tamanho e desempenho dos switches ´e o tamanho dos buffers de entrada e sa´ıda. A Figura 8 mostra a arquitetura de um switch constitu´ıdo basicamente de buffers de E/S, multiplexadores e de um bloco de l´ogica de roteamento. Este switch possui 5 pares de canais de E/S, o que possibilita o envio e recebimento de dados dos quatro switches vizinhos (Norte, Sul, Leste, Oeste) e do recurso local da plataforma ao qual o switch ´e conectado, simultaneamente, garantindo assim um alto throughput durante a comunica¸c˜ao.

mux ns lo r* rni Buffers s Buffers mux n s* l o r l Buffers m u x n s l * o r n Buffers mux n* s l o r o Buffers m u x n s l o * r RoteamentoL´ogica de

Figura 8: Arquitetura interna de um switch

A pr´oxima se¸c˜ao apresenta o Modelo de Referˆencia OSI adotado para identificar o papel exercido por cada elemento de rede em uma rede de computadores e em uma NoC.

1.2 Redes Embutidas 25