Diverses impl´ ementations - Application ` a l’optimisation du r´ eseau principal de routes

5.4 Application ` a l’optimisation du r´ eseau principal de routes

5.4.1 Diverses impl´ ementations

Para realizar o particionamento, foi implementada uma ferramenta que tem como entrada uma aplicação descrita em XML (em inglês, extensible markup language). Os principais propósitos de usar XML são: (i) a facilidade de compartilhamento de dados por diferentes ferramentas de projeto; (ii) a facilidade de documentar a aplicação; e (iii) a extensibilidade da linguagem, uma vez que esta permite que sejam adicionados mais tags ao arquivo de texto sem prejudicar a estrutura dos dados já especificados. Desta maneira, outras ferramentas podem compartilhar o mesmo XML, tornando um formato intermediário mais eficiente. Além do mais, arquivos XML são normalmente menos restritivos do que formatos de documentos proprietários [SAL09].

Na descrição da aplicação (TCG) existem características que devem ser levadas em consideração para obtenção de resultados desejados, enquanto que outras devem ser relevadas. Exemplos destas características são o tamanho do tile que é irrelevante para o cálculo do tempo de execução, enquanto que o tempo de execução de uma tarefa em um dado processador é imprescindível para realizar balanceamento de carga. Sendo assim, a aplicação e a arquitetura alvo são descritas através de três tags XML ilustradas na Figura 9:

 TARGET_ARCHITECTURE – contém uma lista de tipo de processadores e uma lista de processadores que pertencem a cada tipo de processador;  APPLICATION_CHARACTERIZATION – caracteriza as tarefas da aplicação

para os tipos de processadores disponíveis na arquitetura alvo;

de comunicação entre as tarefas.

<SYSTEM_SPECIFICATION> <TARGET_ARCHITECTURE> <PROCESSOR_TYPE_LIST>…</PROCESSOR_TYPE_LIST> <PROCESSOR_LISTS>…</PROCESSOR_LISTS> </TARGET_ARCHITECTURE> <APPLICATION_CHARACTERIZATION> <TASK_LIST>…</TASK_LIST> </APPLICATION_CHARACTERIZATION> <APPLICATION_DESCRIPTION> <COMMUNICATION_TASK_LIST>…</COMMUNICATION_TASK_LIST> </APPLICATION_DESCRIPTION> </SYSTEM_SPECIFICATION>

Figura 9 _{– Esqueleto de uma especificação de plataforma e aplicação MPSoC em formato} XML.

Dentro da tag TARGET_ARCHITECTURE, o primeiro campo (PROCESSOR_TYPE_LIST) contém uma lista de tipos de processadores, onde cada processador da lista é descrito por características físicas, tais como dimensões e freqüência. No caso de um MPSoC homogêneo - foco deste trabalho, apenas uma entrada é necessária. Porém, para facilitar extensões futuras da linguagem de entrada, este campo está sendo planejado para dar suporte a arquiteturas heterogêneas A Figura 10 apresenta um exemplo de um formato aceito pelo campo PROCESSOR_TYPE_LIST, onde está contida uma lista com dois tipos de processadores.

<PROCESSOR_TYPE_LIST>

<PROCESSOR_TYPE type="MIPS">

<PROCESSOR_TYPE type="PowerPC">

</PROCESSOR_TYPE_LIST>

Figura 10 _{– Descrição exemplo de campos da tag PROCESSOR_TYPE_LIST, contendo uma} lista de tipos de processadores com suas características físicas. A figura ilustra dois tipos de processadores contendo suas freqüências de operação e suas dimensões. Por exemplo, no caso do processador MIPS, este opera a 1,2GHz, tem como largura 1,2mm e altura 2,5mm.

Na Figura 11, é identificada a lista de processadores que pertencem a cada tipo de processador (PROCESSOR_LISTS). Esta lista é utilizada para informar quantos conjuntos terá a partição. Além disto, os nomes aqui descritos podem ser utilizados para a atividade de mapeamento, onde os processadores ficam posicionados fisicamente em

tiles específicos.

<PROCESSOR_LISTS>

<PROCESSOR_TYPE type = "MIPS"> <LIST> p1 p2 </LIST> </PROCESSOR_TYPE>

<PROCESSOR_TYPE type = "PowerPC"> <LIST> p3 p4 p5 p6 </LIST> </PROCESSOR_TYPE>

</PROCESSOR_LISTS>

Figura 11 _{– Campo que contém, para cada tipo de processador, uma lista de identificadores} (nomes) de processadores deste tipo. A figura ilustra dois tipos de processadores. Por exemplo, os nomes p1 e p2 identificam processadores do tipo MIPS.

A Figura 12 exemplifica caracterizações de tarefas da aplicação para os tipos de processadores disponíveis na arquitetura alvo. Esta caracterização é definida pela tag TASK_LIST. As tarefas são caracterizadas em termos de: (i) potência média dissipada pelo processador (power), quando este executa a tarefa; (ii) áreas de dados (data) e de código (code), obtidas pela compilação da tarefa no sistema operacional que estará executando no processador; e (iii) percentual de processamento requerido pela tarefa (cpuUse).

<TASK_LIST>

<PROCESSOR_TYPE type="PowerPC" power="20.12" data="3865" code="2793" cpuUse="34.5"/> <PROCESSOR_TYPE type="MIPS" power="13.5" data="22" code="334" cpuUse="24.6"/>

</TASK>

<PROCESSOR_TYPE type="PowerPC" power="26" data="86" code="49" cpuUse="23.7"/> <PROCESSOR_TYPE type="MIPS" power="30" data="2458" code="8368" cpuUse="29.3"/> </TASK>

</TASK_LIST>

Figura 12 _{– Caracterização de tarefas da aplicação frente aos tipos de processador} disponíveis. A figura ilustra um exemplo sintético de caracterização de duas tarefas (T1 e T2) em dois processadores distintos (MIPS e PowerPC). Por exemplo, a tarefa T1 quando executada no processador PowerPC dissipa 20.12 uW (micro watts) de potência, ocupa 3865 KB (kilobytes) de área de dados e 2793 KB de área de código, e requer 34.5% de processamento. Esta mesma tarefa executada em um processador MIPS dissipa 13.5 uW de potência, ocupa 6422 KB de área de dados e 334 KB de área de código, requerendo 24.6 % de processamento.

Por fim, a aplicação também é caracterizada pelo volume de comunicação entre as tarefas. Esta caracterização é obtida com a tag COMMUNICATION_TASK_LIST, tal como ilustrado no trecho sintético de descrição XML da Figura 13. Nela estão definidas a identificação da tarefa que origina e a que recebe a comunicação, além da quantidade de

bytes da comunicação em kB (kilobytes).

<COMMUNICATION_TASK_LIST> <SOURCE_TASK source = "T1">

<SOURCE_TASK source = "T2">

</COMMUNICATION_TASK_LIST>

Figura 13 – Descrição da aplicação em relação à inter-comunicação de suas tarefas. Aqui é descrito um trecho sintético contendo duas tarefas que originam a comunicação (T1 e T2) e 3 tarefas que recebem as comunicações (T1, T2 e T3). Por exemplo, existe uma comunicação que parte da tarefa T1 em direção à tarefa T2 com o volume de comunicação igual a 250 kB.

5 O FRAMEWORK PALOMA

Este capítulo descreve o framework PALOMA, do inglês, Partitioning Algorithm for MPSoC Automated Design, que é utilizado para automatizar a geração de aplicações paralelas sintéticas e também particionar tarefas em grupos de tarefas mapeáveis em processadores do MPSoC alvo.

A Figura 14 ilustra a interface principal do framework. O primeiro conjunto de parâmetros servem para caracterizar a NoC (NoC Characterization). Estes são divididos em três grupos: (i) parâmetros de topologia da NoC (Topology Parameters), (ii) parâmetros de consumo de energia da NoC (Energy Parameters), e (iii) parâmetros para definir a freqüência de operação e o número de ciclos necessários para realizar transferência de informação entre roteadores (Timing Parameters).

Figura 14 – Interface de abertura do PALOMA.

Quatro parâmetros definem a infraestrutura de comunicação:

framework: (i) Mesh - topologia malha 2D, roteamento XY e chaveamento wormhole; (ii) Torus - topologia toro 2D, roteamento XY e chaveamento wormhole;

2. NoC (lines, columns) – Número de tiles da Noc em linhas e colunas;

3. Tile (width, height) – Largura e altura dos tiles em mm. Permite estimar o comprimento das conexões entre roteadores;

4. Router (Buffer length) – Número de elementos que compõem as áreas de armazenamento temporário das entradas de cada roteador. A largura de cada área de armazenamento temporário é de um phit;

O segundo conjunto de itens contém parâmetros que permitem estimar o consumo de energia das NoCs disponibilizadas:

1. Without transitions – Para modelos computacionais que consideram transição de bits, estes campos representam os consumos de energia na ausência de transições entre phits consecutivos. Para os demais modelos, estes campos representam consumos médios de energia para phits. Os campos são: (i) ELWPhit (conexão horizontal) e ELHPhit (conexão vertical) - energia dinâmica de um phit consumida em uma conexão entre roteadores. Para NoCs retangulares, ELWPhit e ELHPhit são iguais e equivalem a ELbit multiplicado pelo número de bits de um phit; (ii) ECPhit - energia dinâmica de um phit consumida em uma conexão entre um roteador e uma núcleo local ao tile. Equivale ao ECbit multiplicado pelo número de bits de um phit; (iii) ESPhit - energia dinâmica de um phit consumida no circuito de controle de um roteador. Equivale ao ESbit multiplicado pelo número de bits de um phit; (iv) EBPhit - energia dinâmica de um phit consumida por um elemento do circuito de armazenamento. Equivale ao EBbit multiplicado pelo número de bits de um phit.

2. With Transitions – Parâmetros usados apenas nos modelos que consideram transição de bits. Representa os consumos de energia quando ocorrer transição entre bits de phits consecutivos considerando agora transições existem as seguintes equivalências: (i) ELWS_Phit e a ELWPhit; (ii) ELHS_Phit e ELHPhit; (iii) ECS_Phit e ECPhit; (iv) ESS_Phit e ESPhit; (v) EBS_Phit e EBPhit.

3. PRouter – Potência estática dissipada por todos os elementos ativos de um roteador, somado com a potência dinâmica dissipada pelos circuitos do roteador que operam mesmo frente a ausência de tráfego.

Por fim são descritos os parâmetros que permitem modelar o comportamento temporal da NoC:

utilizado para determinar o tempo de execução da aplicação e o consumo de energia estática de toda rede, e dinâmica dos circuitos que operam mesmo frente a ausência de tráfego;

2. Cycles Linking – Número de ciclos de relógio necessário para realizar a transmissão de um phit de uma conexão entre roteadores ou entre roteador e núcleo local;

3. Cycles Routing – Número de ciclos de relógio para rotear um pacote de um canal de entrada para um canal de saída de um roteador.

Dentro de System Application Tools da Figura 15 encontram-se os botões: (i) Load XML que carrega aplicações descritas em XML; (ii) Load NoC que carrega parâmetros da NoC previamente salvos em arquivo e (iii) Generate synthetic application que abre uma nova interface gráfica para poder descrever classes de aplicações, que embora sintéticas, pudessem ter comportamento similar ao de aplicações embarcadas. Para tanto, boa parte dos parâmetros são expressos em termos de distribuições Gaussianas. A Figura 15 ilustra a interface gráfica, contendo parâmetros que permitem definir características da aplicação e da arquitetura alvo (MPSoC homogêneos).

Figura 15 _{– Interface gráfica da ferramenta de geração de aplicações sintéticas. Os valores} aqui apresentados são meramente ilustrativos.

Os parâmetros usados para especificar o MPSoC são: (i) Number of processors, que contém o número absoluto de processadores presentes no MPSoC alvo, considerando um processador por tile; (ii) Processor, contendo características do tipo de processador. As características aqui descritas são: Frequency - frequência de operação (em MHz), Width - largura física do processador (em mm), Height - altura física do processador (em mm) e Name - nome do tipo de processador (um identificador).

A aplicação é definida pelos parâmetros: (i) Number of tasks, que contém o número total de tarefas da aplicação a ser sintetizada; (ii) Task characterization, contendo quatro sub campos que caracterizam as tarefas quando executadas na arquitetura alvo; e (iii) Task communication, que contém dois sub campos com o informações sobre a comunicação entre as tarefas da aplicação.

Os sub campos Data occupation e Code occupation de Task characterization contém informações sobre a quantidade de dados e código, respectivamente, de uma dada tarefa, e são obtidos após a compilação de cada tarefa para o processador especificado. Os sub campos Power dissipation e Processor occupation de Task characterization descrevem o consumo de energia e o percentual de ocupação de uma tarefa quando executada no processador especificado.

Todos os campos contendo média, desvio padrão e intervalo (valor máximo e mínimo) produzem valores aleatórios com probabilidade que respeita uma distribuição Gaussiana. Uma distribuição Gaussiana permite que a aplicação sintética gerada possa ser direcionada para uma determinada classe de aplicações, tal como IO-bounded ou CPU-bounded. O objetivo aqui é que ao analisar uma aplicação, mesmo que sintética, o projetista possa ter idéia de como o particionamento iria se comportar como uma aplicação real, uma vez que esta fizesse parte da mesma classe de aplicações.

Após o preenchimento de todos os campos dispostos na interface, é possível gerar uma aplicação sintética - através do botão OK. Esta aplicação estará em um arquivo de texto no formato de XML. É possível também preencher os campos automaticamente com valores padrões - pressionando o botão Default values, ou então gerar aleatoriamente esses valores - através do botão Random values.

Uma vez tendo gerada a aplicação sintética, o projetista pode particionar a mesma através da configuração do conjunto de itens localizado dentro de Partition Tools, que contem: (i) requisitos que pretende explorar, como por exemplo, redução do consumo de energia ou balanceamento de carga e, (ii) restrições, como por exemplo, limitar o número de tarefas agrupadas em um mesmo processador, objetivando minimizar ou maximizar a

função custo de particionamento. Ou seja, objetivando obter particionamentos ótimos (aqueles com menor custo de particionamento) ou péssimos (aqueles com maior custo de particionamento). Estas partições podem ser obtidas através dos botões Generate an optimum partition e Generate reference partition (worst), respectivamente.

Dans le document Optimisation de graphes sous contrainte géométrique : création d'un réseau de routes aériennes pour un contrôle Sector-Less (Page 80-82)