ETAPAS DE COPROJETO

As metodologias de coprojeto hardware/software de sistemas embutidos apresentam diferenças em relação ao fluxo (processo) de projeto adotado. Entretanto, na maioria dos casos, as etapas envolvidas são basicamente as mesmas, diferindo na forma como são tratadas: manualmente ou automaticamente. As etapas incluem:

a) Especificação do sistema;

b) Particionamento hardware/software; c) Escalonamento/alocação;

d) Síntese (hardware, software, interface);

e) Verificação (verificação formal, simulação, prototipação); f) Avaliação do projeto.

A figura 5.1 apresenta um fluxo de projeto, proposto por Kalavade e Lee [27], para uma metodologia genérica de coprojeto hardware/software, o qual não está voltado para um

framework em particular, embora seja aplicado na metodologia Ptolemy. Vejamos, na

seqüência, como a metodologia Ptolemy trata desse fluxo de projeto; nesta discussão, os números entre parênteses correspondem aos estágios mostrados na figura 5.1.

Dada a especificação de um sistema, o projetista desenvolve um algoritmo usando simulações funcionais em alto nível (1), independentes de qualquer forma de implementação. O projetista então particiona o algoritmo em hardware e em software (2), guiado por requisitos de velocidade, complexidade e flexibilidade. Componentes que apresentam funções complexas (alto custo em hardware) ou que exijam flexibilidade (ou programabilidade, útil, por exemplo, em casos de configuração de parâmetros ou em expansão futura de funcionalidade), são associados para implementação em software. Operações que tenham requisitos críticos de velocidade de execução são associadas para implementação em

hardware. Para explorar o espaço (alternativas) de projeto, o projetista deve repetir esta

Figura 5.1. Metodologia genérica de coprojeto (adaptação de Kalavade e Lee [27]). 1 3 4 Interface Hardware/Software Configuração de Hardware Software para Componentes Programáveis Especificação 2 5 6 7 8 9 Particionamento Hardware/Software Síntese de Hardware

1. Analógico versus digital 2. Seleção da arquitetura 3. Seleção do tamanho de

palavra dos registradores 4. Hardware dedicado:

FPGA, ASIC, ...

Síntese de Software

1. Seleção do gerador de código

2. Adequação do algoritmo às características dos registradores

3. Seleção do escalonador

4. Particionamento do software entre memórias, processadores, dispositivos de E/S,...

Síntese de Interface 1. Comunicação entre processadores 2. Comunicação entre hardware dedicado e processadores Simulação do Sistema

Verificação do Projeto Avaliação do Sistema

1, 2, 3, ... ?

Desenvolvimento do Algoritmo

Após o particionamento, seguem-se as etapas de síntese de hardware (3), software (4) e interface (5), as quais estão profundamente amarradas, pois mudanças em uma delas trarão efeitos imediatos sobre as outras duas.

Decisõesdeprojetoemhardwareincluemaseleçãodosprocessadoresprogramáveis (afetando a seleção do gerador de código para módulos em software) e a determinação do número de processadores e de seu esquema de interconexão (influenciando o particionamento e escalonamento do código e a síntese da interface hardware/software); processadoresprogramáveis incluem ASIPs e processadores de propósito geral. Na síntese de hardware dedicado, as escolhas variam desde a geração de datapaths personalizados até a programação de FPGAs. Ao projetar datapaths personalizados, o projetista deve escolher o tamanho das palavras dos registradores.

Em relação ao software, no caso de processadores de ponto fixo, algumas modificações algorítmicas podem ser necessárias para minimizar os efeitos da precisão finita. A síntese de software envolve o particionamento e o escalonamento do código da aplicação entre os vários processadores, além da síntese do código para a comunicação entre estes processadores e os demais dispositivos. Estas decisões dependem da arquitetura escolhida. Neste processo de particionamento de software e escalonamento (também denominado de particionamento temporal), o projetista toma decisões com base na otimização de funções custo. Exemplos destas funções representam o custo de comunicação, a largura da banda de memória e a capacidade de memórias locais e compartilhadas.

A síntese de interface envolve, em relação ao hardware, a adição de latches, FIFOs ou decodificadores de endereços. Em relação ao software, envolve a inserção de código para operações de E/S e de sincronização por semáforos.

Uma forma típica de tratamento deste problema cíclico (a síntese) é começar com um projeto e trabalhar sobre este iterativamente para explorar diferentes opções.

A próxima etapa é a de simulação heterogênea (6). Em particular, o hardware simulado tem que rodar o software gerado. Isto envolve a interação de vários simuladores diferentes, caso várias linguagens de especificação tenham sido utilizadas. Uma descrição sobre como o ambiente Ptolemy trata desta etapa é dada mais adiante.

Os resultados da simulação são utilizados para verificar (7) se o projeto atende às especificações da aplicação. Tendo realizado a síntese de hardware e de software para uma determinada alternativa de projeto, o projetista pode estimar área, consumo, caminho crítico, taxas de utilização de componentes e barramentos, entre outros fatores. Após usar estas estimativas, para avaliar o projeto quanto às restrições (8), o projetista poderá reparticionar o sistema ou tentar diferentes opções de síntese (retorno no fluxo de projeto, etapa 9). Desta forma, o processo como um todo é iterativo. As etapas (7) e (8) são tratadas manualmente no Ptolemy.

Para o tratamento destas etapas na metodologia Ptolemy, a qual é uma abordagem heterogênea, seus criadores conceitualizaram domínios de projeto, os quais utilizam-se de determinados conjuntos de ferramentas e representações para auxílio ao projeto. Na referência [27] são descritos com algum detalhe os domínios SDF, Thor e Silage. Além destes, são mencionados os domínios DDF (dynamic dataflow) e DE (discret event).

SDF (synchronous dataflow) é utilizado nas fases de desenvolvimento algorítmico, síntese de hardware (modelagem funcional de componentes analógicos) e síntese de software, etapa na qual este domínio recebe um nome de acordo com o gerador de código designado, tal como CGC (code generation in C), CG56 (code generation in DSP56000

family), CG96 (code generation in DSP96000 family), entre outros. Por permitir a

modelagem funcional de componentes analógicos, tais como filtros e conversores, este domínio é utilizado também na fase de simulação do sistema.

De distribuição livre, Thor é um simulador funcional para hardware digital, podendo simular desde portas lógicas até chips DSP programáveis. Permitindo simulação de sistemas multiprocessadores, é fundamental na seleção da arquitetura, durante a fase de síntese de hardware. No caso deste tipo de sistema (multriprocessadores), Thor é utilizado também na síntese de interface. Na fase de simulação do sistema, componentes analógicos (domínio SDF) são inseridos no modelo de simulação arquitetural Thor, através de wormholes (comunicação – interface – entre as partes descritas em domínios distintos).

O domínio Silage é utilizado para simulações bit-true de componentes associados a

hardware dedicado. Estas simulações são utilizadas durante a fase de síntese de hardware

para análise de efeitos de precisão finita, ajuste do algoritmo para tamanhos limitados de palavras (de dados ou de controle) e para a determinação do tamanho ideal das palavras. O código Silage serve de entrada para ferramentas de síntese de datapaths personalizados. Estas ferramentas são capazes de estimar o consumo, a área e o caminho crítico. Blocos Silage são adicionados ao modelo de simulação do sistema (Thor) para representar o

hardware dedicado.

A manipulação de informações em diferentes domínios torna o sistema Ptolemy flexível e poderoso, devido ao aspecto da modularidade. Os domínios tratam de diferentes tipos de atividades (modelagem, simulação, geração de código, estimativas, síntese), as quais estão intrinsicamente amarradas e possuem suas próprias dificuldades de desenvolvimento. Isolando-se os domínios em módulos distintos, os quais podem ser associados com uma interface apropriada, obtém-se uma plataforma de projeto flexível e poderosa.

Ptolemy é flexível devido à fácil substituição de um domínio por um análogo (por exemplo, a substituição de um domínio de geração de código por outro) e, também, devido à facilidade de expansão (pode-se introduzir facilmente um novo domínio no sistema, bastando- -se atender aos requisitos da interface denominada EventHorizon).

A plataforma Ptolemy é poderosa devido à possibilidade de poder testar várias alternativas de projeto (alteração de domínios) e, também, devido ao aprimoramento que pode ser dado de forma particularizada em um domínio qualquer, sem a necessidade de adequação dos demais domínios (desde que a interface entre os domínios seja mantida).

O exemplo da metodologia Ptolemy serve para demonstrar quão amarradas estão as tarefas que devem ser executadas ao longo do processo de projeto de um sistema embutido. Na seqüência, são vistas particularidades a respeito destas tarefas, abrangendo outras metodologias.

5.3. ESPECIFICAÇÃO

Modelos conceituais (capítulo 2) são utilizados para representar diferentes aspectos inerentes ao sistema. Para que possam ser trabalhados em computador, estes modelos precisam ser capturados, cada qual, por alguma linguagem de especificação. A especificação gerada é então tratada pelas demais tarefas do fluxo de projeto.

A especificação de sistemas na metodologia POLIS está centrada sobre uma única representação baseada em FSM, denominada CFSM (Co-design Finite-State Machine – Máquina de Estados Finitos para Coprojeto) [30]. CFSM, assim como FSM, transforma um conjunto de entradas em um conjunto de saídas utilizando-se de um conjunto finito de estados internos. A diferença entre os dois modelos é que o modelo de comunicação síncrona de FSMs concorrentes (HCFSM, seção 2.2.1) é substituído, no modelo CFSM, por um tempo de reação finito, não-nulo. Este modelo de computação pode ser descrito como globalmente assíncrono, localmente síncrono.

Cada elemento de uma rede de CFSMs descreve um componente do sistema a ser modelado. A especificação CFSM é independente de implementação em hardware ou em

software. Embora executem a mesma computação para cada uma das transições da CFSM, hardware e software exibem características de atraso diferentes. Uma implementação

síncrona em hardware a partir de uma CFSM pode executar uma transição em 1 ciclo de

clock, enquanto uma implementação em software exigirá mais do que 1 ciclo de clock.

CFSM é um modelo que permite a utilização de técnicas de síntese e de verificação, uma vez que muitos resultados teóricos e ferramentas para o modelo FSM podem ser adaptados para CFSM. A referência [30] mostra como uma abordagem para verificação formal baseada em autômatos pode ser aplicada para modelos CFSM. Numa abordagem baseada em autômatos, um sistema é modelado por um autômato de estados finitos, sendo a linguagem desse autômato (Lsistema) considerada o comportamento do sistema. A linguagem

do autômato corresponde a um conjunto de seqüências de entradas e saídas, observável nas portas do sistema. Neste contexto, a tarefa da verificação formal é mostrar que todas estas seqüências são aceitáveis. As seqüências aceitáveis são especificadas como uma linguagem de um outro autômato (Laceitáveis), de maneira que o problema da verificação fica reduzido à

checagem da linguagem Laceitáveis estar contida na linguagem Lsistema.

Assim como outros modelos baseados em FSM, CFSM apresenta o problema de explosão no número de estados, dificultando a manipulação do modelo. A estratégia sugerida pelos autores em [30] para superar esse problema é realizar agrupamentos de determinados estados em um único estado (tratar um grupo de estados como um único estado). Desta forma, executa-se uma ascensão para um nível de abstração superior e conseqüentemente diminui-se a complexidade do problema.

A metodologia proposta por Wolf et al. [31] baseia-se na especificação funcional em nível de sistema. O projetista especifica o sistema a ser tratado através de objetos e métodos, classificados em 3 grupos: os de hardware, de software e de coprojeto. Neste último, enquadram-se os módulos do sistema compostos por objetos e métodos que poderiam ser implementados tanto em hardware quanto em software. Os módulos dos grupos de hardware e de software são descritos em C++, enquanto os módulos de coprojeto são descritos numa linguagem denominada OOFS (Object-Oriented Functional Specification).

Para ilustrar melhor a importância de uma especificação funcional, é apresentado, na seqüência, o restante do fluxo de projeto da metodologia de Wolf et al.

Após a especificação, é feito o particionamento: escolhe-se, manualmente, para cada módulo de coprojeto, a sua melhor implementação. Os módulos a serem implementados em hardware são transformados (via tradutor) em código da HDL Bestmap-C (visando síntese) e em código C++ (visando simulação). Os módulos escolhidos como de software são transformados pelo tradutor em código C++.

A próxima etapa é a de simulação, onde os diversos fontes C++, gerados para os módulos e para as templates (modelos) de interface hardware/software, são compilados e executados, visando a verificação de sua correção.

A avaliação de desempenho do software gerado para os módulos de coprojeto é feita através de utilitários padrão C para medida de desempenho. Já para os módulos de coprojeto associados a hardware, a avaliação de desempenho é feita sobre resultados de estimativas de área e de desempenho fornecidas pelo Bestmap-C.

Os resultados da avaliação de desempenho podem determinar a necessidade de se tomar diferentes decisões de particionamento ou de se realizar a síntese. A síntese de

hardware e de interfaces hardware/software é realizada a partir da descrição em Bestmap-C.

As etapas automatizadas da metodologia de Wolf et al. são as de simulação, avaliação de desempenho e síntese. Entretanto, estas etapas são automáticas somente dentro das atividades a que elas se destinam (não há integração), sendo a avaliação de desempenho muito restrita. Desta forma, a metodologia, apesar de ajudar no trabalho do projetista, relega ao mesmo decisões importantes, como a determinação da melhor escolha de particionamento, a verificação da funcionalidade do sistema (através dos resultados de simulação) e a escolha das interfaces hardware/software.

Pelo exposto em [31], pode-se concluir que a argumentação dos autores acerca da "neutralidade" da especificação funcional está bem ilustrada, uma vez que demonstraram (através de exemplos) como métodos funcionais em OOFS podem gerar tanto descrições em

software quanto em hardware. Desta forma, a especificação funcional permite um número

maior de implementações do que uma especificação operacional, a qual tende a adotar uma sintaxe de uma dada linguagem de programação (voltada para a descrição de software) ou a sintaxe de uma HDL (voltada para a descrição de hardware). Esta "tendência" pode comprometer a qualidade e a quantidade de formas de implementação em hardware e

software que podem ser levadas em conta, devido à especificidade de domínio que

linguagens de programação e HDLs possuem. Assim, uma especificação funcional coloca-se numa posição neutra, em relação à decisão de implementar um componente de um sistema em

hardware ou software, simplificando decisões de particionamento, ao permitir que várias

alternativas de implementação possam ser testadas.

Nesta seção foram vistos dois exemplos de especificação em nível de sistema. Ressalta-se, no entanto, que modelos conceituais de especificação (capítulo 2) podem ser utilizados em várias fases do fluxo de projeto de uma metodologia de coprojeto

hardware/software, de acordo com a ênfase dada pela metodologia. Nas próximas seções, é

vista a importância de modelos de especificação para o tratamento de questões relativas às tarefas de particionamento, escalonamento e alocação.