Microsoft word - pap-046-3.doc

METODOLOGIA ORIENTADA AO PROJETISTA PARA SYSTEM-LEVEL DESIGN
Reinaldo Silveira e Wilhelmus A. M. Van Noije LSI - Depart. de Engenharia de Sistemas Eletrônicos da Escola Politécnica da Universidade de São Paulo, Av. Prof. Luciano Gualberto n.158, trav. 3, Cidade Universitária, ABSTRACT


A great deal of the discussion about design of new EDA tools and methodologies concern about the conciliation between
designers needs and programmers capabilities. This work addresses this problem, proposing a new design methodology that
instructs how to integrate different tools into a common framework and which are the requirements of this framework to
assure productivity at the system level design. This approach is called "Designer Oriented Methodology" (DO), and uses
the so called "Game Like Development" concept (GLD) and the pure object-oriented language Self as the main element for
this integration.

Uma grande preocupação sobre o desenvolvimento de ferramentas de auxílio a projeto eletrônico (EDA), atualmente,
refere-se a conciliação entre as necessidades dos projetistas e os interesses dos programadores. Este trabalho aborda este
problema, propondo uma nova metodologia de projeto que sugere como pode ser a integração de diferentes ferramentas
num framework comum e quais devem ser os requisitos deste framework para que seja assegurada a produtividade no nível
de projeto de sistema. Esta proposta chama-se "Designer Oriented Methodology" (DO), e emprega uma série de conceitos
e abstrações inclusive a que chamamos de "Game Like Development" (GLD). Como elemento principal para a
implementação da proposta usa-se a linguagem orientada a objeto Self.
METODOLOGIA ORIENTADA AO PROJETISTA PARA SYSTEM-LEVEL DESIGN
Reinaldo Silveira e Wilhelmus A. M. Van Noije LSI - Departamento de Engenharia de Sistemas Eletrônicos da Escola Politécnica da Universidade de São Paulo, Av. Prof. Luciano Gualberto, n.158, trav. 3, Cidade Universitária, de 10% do pessoal somente para a manutenção do fluxo de projeto. A fim de contornar estes problemas é Uma grande preocupação sobre o desenvolvimento de necessário o rompimento com as atuais metodologias e ferramentas de auxílio a projeto eletrônico (EDA), introduzir uma nova, que seja capaz de lidar com todos os atualmente, refere-se a conciliação entre as necessidades problemas atuais de forma elegante e oferecer uma nova dos projetistas e os interesses dos programadores. Este perspectiva de evolução a medida que novos métodos e trabalho aborda este problema, propondo uma nova algoritmos forem surgindo. Este trabalho propõe o que metodologia de projeto que sugere como pode ser a acreditamos ser esta nova metodologia. Chamada de integração de diferentes ferramentas num framework "Metodologia Orientada ao Projetista" (DO, Designer comum e quais devem ser os requisitos deste framework Oriented methodology), ela consiste num ambiente capaz para que seja assegurada a produtividade no nível de de oferecer ao usuário/projetista condições apropriadas projeto de sistema. Esta proposta chama-se "Designer para que o mesmo possa trabalhar livre de interrupções e Oriented Methodology" (DO), e emprega uma série de distrações, mantendo-o sempre atento e em prontidão para conceitos e abstrações inclusive a que chamamos de resolver qualquer problema que venha a ocorrer assim que "Game Like Development" (GLD). Como elemento o mesmo seja percebido. Nesta metodologia, todas as principal para a implementação da proposta usa-se a informações são apresentadas de forma a reforçar a linguagem orientada a objeto Self.
atenção do usuário em aspectos específicos do projeto. Este reforço deve ser implementado em todas as formas 1. INTRODUÇÃO
possíveis, assim como um jogo que captura as atenções Atualmente, o estado-da-arte em ferramentas de projeto digital encontra-se numa situação um tanto difícil devido Este trabalho não se trata de um novo algoritmo de ao rápido desenvolvimento das tecnologias de fabricação simulação, síntese ou verificação, mas uma nova proposta de circuitos integrados e da pressão do Mercado por CI's e de integração de todas estas ferramentas e possivelmente sistemas mais complexos, desempenhos cada vez maiores muitas outras num framework que possa evoluir ao longo num tempo muito menor. Acompanhando a bibliografia do do tempo de acordo com as necessidades do projeto. Este assunto, notamos a proliferação de impressionantes frases framework é baseado no que achamos ser mais adequado de efeito como "Systems on a Chip" (SoCs), "Intellectual aos projetistas mantendo-os focados no processo de Properties" (IPs), "High Level Synthesis" (HLS), e somos levados a acreditar que o problema de desenvolvimento destes novos sistemas está bem entendido e resolvido. As próximas seções são divididas da seguinte forma: a Entretanto, constatamos que isto é conseguido a custos seção 2, apresentará uma visão geral das tendências atuais de desenvolvimento de ferramentas de auxílio ao projeto eletrônico (EDA). Estas tendências estão bem As metodologias em uso atualmente são basicamente as estabelecidas por vários anos e representam muito bem a mesmas propostas de quinze a vinte anos atrás, muitas forma com que os projetos são feitos nos dias de hoje. Na adaptações foram introduzidas para acomodar seção 3, apresentaremos as razões que nos levaram a desenvolvimentos mais recentes, entretanto pouco ou elaboração da metodologia orientada ao projetista, e quais nenhum aperfeiçoamento real foi introduzido. Estas os seus requisitos necessários para a sua implementação. metodologias são muito difíceis e caras de serem Na seção 4, introduziremos o conceito de Jogo e como mantidas[3], não é raro uma design house manter até cerca este pode ser aproveitado na perspectiva do Projeto. Na seção 5, mostraremos como usando uma linguagem de alto fluxos de projeto estaria praticamente garantida. Usando a nível podemos implementar um framework que adere às orientação a objetos para esconder a complexidade dos especificações da metodologia. Finalmente na seção 6, modelos de hardware dos programadores/projetistas seria concluiremos este artigo com as considerações finais sobre possível evitar os problemas apresentados no início desta prática. A complexidade do projeto digital tem aumentado consideravelmente nos últimos anos, novas classes de 2. CONSIDERAÇÕES SOBRE AS FERRAMENTAS
problemas aparecem a cada dia. Sem falar no time-to- DE PROJETO ATUAIS
market cada vez menor e dos custos envolvidos. O Mercado apresenta-se muito mais agressivo devido a um Desde o início do projeto de computadores, as linguagens novo perfil de consumidor acostumado a inovações de programação tem sido usadas na modelagem de tecnológicas a cada ano [5]. A preocupação da industria de sistemas digitais complexos [8]. Um grande número de semicondutores tem se concentrado nos problemas técnicas foram elaboradas para modelar os primeiros decorrentes da complexidade ao nível de sistemas, como: sistemas, mas cada novo desenvolvimento parecia sempre reuso, verificação e teste, gerenciamento de projeto, uma nova experiência, principalmente pela dificuldade de software embarcado, otimizações baseadas em custo, e etc. uso destas linguagens numa tarefa tão especifica. Havia Seguindo estas tendências, os esforços dos meios de um consenso que somente uma linguagem especialmente pesquisa tem sido em aumentar a produtividade das desenhada para a descrição de hardware poderia ser de ferramentas de auxílio (EDA) e fluxos de projetos, real utilidade para a industria. Somente em meados da introduzindo modelos de descrição de alto nível para década de 80 surgiram os primeiros padrões industriais de sistemas digitais e novos algoritmos de síntese. linguagens de descrição de hardware (HDL), com o VHDL e o Verilog. Logo, estes padrões tornaram-se O resultado deste processo é uma grande diversidade de comuns nos principais fluxos de projeto. Ao contrário da ferramentas, modelos e interesses conflitantes que é muito captura esquemática, a descrição textual é muito mais difícil de manter gerenciável e atualizado. Outro problema rápida de ser editada, inequívoca e capaz de descrever o serio é que estas ferramentas foram desenvolvidas com sistema em diferentes níveis de abstração. Isto fez com técnicas da ciência da computação, visando um aspecto que fossem estabelecidos níveis de representação muito particular do problema e quase sempre sem apropriados para procedimentos de síntese lógica considerar as formas de utilização das mesmas. Estas (register transfer level - RTL), e níveis de abstração mais condições, na maioria das vezes, não condiz com a elevados para representação e síntese. Seguindo as HDLs, realidade das equipes de desenvolvimento. O ponto de as ferramentas de síntese foram o próximo grande adendo vista do projetista tem sido sistematicamente aos fluxos de projeto. Primeiro as ferramentas de síntese desconsiderado quando são propostas novas metodologias. lógica, depois as de síntese de alto nível, apesar desta Este estado de coisas pode não ser intencional, mas tem última ainda não gozar da mesma popularidade da aumentado os requisitos das equipes de desenvolvimento que precisam se capacitar em conhecimentos/conceitos de programação algumas vezes muito além do escopo das Apesar de seu grande sucesso no meio industrial, as HDLs suas especializações. Isto acaba por aumentar ainda mais padrão não tiveram sucesso em preencher todas as expectativas especialmente da comunidade acadêmica. Suas dificuldades em lidar com diferentes estruturas/tipos Note que isto não é uma simples crítica a pesquisa da de dados e as limitações sintáticas em descrever abstrações ciência da computação em ferramentas EDA, na realidade de níveis mais elevados sinalizavam a necessidade para eles tem feito uma notável contribuição a todo o sistema novos tipos de descrição. Muitos grupos afirmam que o de projeto. A questão é que a pesquisa deve prestar mais caminho é o uso de linguagens de programação de atenção a forma de interação das ferramentas com os seus propósito geral, assim como era feito no início, com uma usuários, seus problemas e limitações, e da forma com que certa ênfase nas linguagens mais populares, como C/C++ as estruturas de dados são processadas a apresentadas no [9,10] ou Java [6]. A idéia é usar o poder e flexibilidade fluxo de projeto. A tripla de operações "edição- destas linguagens para desenvolver um subconjunto compilação-simulação" não é indicada quando se trabalha (funções/objetos) apropriado para as descrições de com altos níveis de abstração. Nestes níveis, as mudanças hardware. Padronizando estes subconjuntos, seria possível devem ser implementadas e verificadas rapidamente, de utilizar a mesma estrutura de desenvolvimento de software forma a não desviar a atenção do projetista do objeto de para o projeto de sistemas. Outro ponto importante, tendo seu trabalho. Apesar de todos os avanços, a imaginação do sido padronizado estes subconjunto de funções, o reuso e a usuário ainda desempenha um fator determinante no troca de IPs estaria garantida. Além disso, por se tratar de processo de desenvolvimento. As ferramentas devem uma linguagem de uso geral a integração em diferentes refletir esta importância, assim como todo o fluxo de compilação, "entrada" corresponde ao arquivo fonte, o compilador ao "filtro" e o programa executável ao "resultado". No exemplo do simulador compilado Com todos estes pontos em mente, este trabalho propõe observamos a mesma coisa: "descrição-compilação- diretrizes para o que pode vir a ser uma nova metodologia simulador", respectivamente. Se tomarmos como exemplo de projeto de sistemas digitais. Uma metodologia que um simulador interpretado veremos o mesmo padrão: adote o ponto de vista do projetista, onde cada ferramenta "descrição-simulador-saída". E assim sucessivamente, assuma o agente humano como fonte/guia principal de quando analisamos outras ferramentas de auxílio. projeto. Isto pode ser conseguido aplicando o conceito de Podemos identificar em cada caso o padrão acima, Jogo (GLD) no desenvolvimento de um framework demonstrando que por mais criativos que os comum que integre as mais avançadas ferramentas, assim programadores procuram ser, eles ainda estão como as mais tradicionais, mas que acima de tudo seja contaminados com um "modus operandi" surgido a mais diferente na forma com que tais ferramentas interagem de 30 anos e que não corresponde com a realidade dos com o agente humano ao longo do processo de A cerca de 15 anos, deu-se início uma difusão mais intensa 3. Desenvolvimento Orientado ao Projetista das interfaces gráficas e "amigáveis" nos sistemas de computação. Entretanto, parece que os programadores Na seção anterior afirmamos que as ferramentas de auxílio continuaram insensíveis as potencialidades desta nova ao projeto são desenvolvidas sob uma visão muito tecnologia. Talvez isto se deu em parte pelas limitações particular de seus criadores. Isto pode ser constatado tecnológicas que se apresentavam na época, mas o mais facilmente quando analisados o modo operacional das provável é que eles ainda continuavam escravos dos mesmas. Tomemos por exemplo um simulador hipotético. antigos conceitos de programação, que acreditamos Existem muitos tipos de simulação, a que estamos acontece até os dias de hoje. Podemos tomar como interessados são os que se referem às simulações exemplo, as ferramentas "gráficas" que se seguiram nesta arquiteturais e RTL. Nestes casos, cada nível hierárquico época e que constituem o fundamento de muitas que corresponde um conjunto de primitivas que constituem a usamos ainda hoje. Tínhamos os editores esquemáticos, base do processo de simulação. Os simuladores também onde editávamos os diagramas dos circuitos que estavam podem ser do tipo Levelized Compiled Code (LCC) ou em desenvolvimento. Quando era necessário efetuar interpretados [7]; ou quanto ao tipo de inferência de alguma coisa realmente útil como por exemplo uma simulação podem ser event-driven ou cycle based. Em verificação (simulação), era necessário gerar um netlist todos estes casos, eles compartilham um ponto em comum: ("entrada"), aplicá-lo ao simulador ("filtro") para se obter a visão (cultural) dos seus criadores. Vejamos a forma os resultados ("saída"). E analisá-lo, tomando-se estes como utilizamos estes simuladores: independente do tipo, resultados ("nova entrada") e aplicá-lo a um gerador de event-driven ou cycle based, os simuladores compilados formas de onda ("filtro") para que fosse gerado uma partem de uma descrição do circuito em termos de representação gráfica ("saída"), conforme ilustra a Figura primitivas, que é compilada gerando um programa que 1. Ou seja, apesar deste grande recurso os programas corresponde ao simulador para aquele circuito. Este nunca deixaram de funcionar desta mesma forma. A forma programa é então executado em função de entradas que tradicional da ciência da computação. correspondem às condições em que o circuito deve ser verificado. Podemos ver aqui um padrão de operação, que devemos concordar, faz um perfeito paralelo com a forma de desenvolver programas, guardada as devidas proporções. Figura 1. Esquema tradicional de operação de programas.
Este padrão é o que aparece em todos os ciclos de Esta forma de operação, mostrou-se efetiva nos últimos 40 desenvolvimento de programas, ou seja "entrada-filtro- anos mas já tem mostrado sinais de cansaço no decorrer da resultado". "Entradas e resultados" correspondem a última década. Este modelo de computação surgiu numa arquivos com funções especiais, "filtro" corresponde a um época em que os computadores eram máquinas agente de transformação que operando sobre o arquivo de praticamente inacessíveis a usuários comuns, e que entrada produz uma seqüência de dados de saída que é somente especialistas gabaritados podiam operar. Naquela armazenado em "resultados". Isto pode ser observado em época também o custo de cada equipamento era tão alto quase todo o universo da computação contemporânea, que o sua existência somente poderia ser justificada se o sendo um dos fundamentos dos sistemas UNIX. Na seu índice de utilização fosse de 100%, 24 horas por dia. Sob estas circunstâncias é plenamente justificado o conceito de Jogo aplicado ao desenvolvimento, (GLD) modelo acima, que aliado aos modestos desempenhos "Game Like Development". A linguagem Self nos fornece existentes, permitiam as operações em batch e background o modelo computacional para a implementação da sem intervenção dos operadores. Entretanto, o que metodologia através do conceito de objetos concretos, o observamos nas últimas duas décadas foi o aparecimento conceito de Jogo por sua vez determina como devem se das máquinas de uso pessoal, que possibilitou ao usuário apresentar as aplicações em relação ao agente humano, o comum o acesso a estes equipamentos. Apesar do qual não mais é considerado como elemento separado do tremendo desenvolvimento tecnológico a visão dos programadores continuaram imersas na era dos mainframes. Para o usuário comum, os programas 4. CONCEITO DE JOGO NO DESENVOLVIMENTO
continuam difíceis de serem operados, pouco intuitivos, e Nesta seção abordaremos uma parte importante da metodologia que é o conceito de Jogo aplicado ao Os aperfeiçoamentos que presenciamos atualmente, são desenvolvimento (GLD). Para entender melhor o conceito modestos se considerássemos as reais potencialidades da de Jogo, emprestaremos alguns conceitos e observações tecnologia existente. O único inconveniente seria os da filosofia [4] como também invocaremos o senso interesses econômicos das corporações que dominam o comum que cada um de nós possuímos em relação ao setor. Veremos na seção 5, que apenas uma mudança nos tema. Jogo não é algo estranho para ninguém, de fato ele paradigmas de implementação pode abrir uma grande tem estado presente nas nossas vidas desde a infância, possibilidade de desenvolvimento, sem as inconveniências fazendo parte das principais etapas de desenvolvimento do individuo. Inclusive muitos animais apresentam comportamento que indicam a existência de jogos com O objetivo deste trabalho refere-se principalmente a finalidades diversas. Através dos jogos desenvolvemos metodologia de desenvolvimento de sistemas digitais em qualidades específicas que nos são úteis na vida adulta ou geral, mas os princípios básicos da metodologia podem ser que nos ajudam a contornar situações difíceis facilmente estendidos para outras áreas de conhecimento possibilitando relaxamento, distração, diversão. Para não que não estejam diretamente ligadas a ciência da entrarmos em infinitas discussões filosóficas, faremos a computação mas que carecem de ajuda computacional. A seguir alguns comentários que achamos pertinentes em critica principal diz respeito ao modo operacional das relação ao Jogo e a contrapartida em relação a ferramentas disponíveis atualmente e da distância conceitual entre programas e usuários, que fazem com que estes últimos participem como meros observadores em • Apesar de seu caráter primordialmente lúdico, o Jogo possui uma seriedade própria que independe dos elementos que o jogam. Esta seriedade determina um A metodologia orientada ao projetista (DO), consiste no mundo onde se desenrolam as ações e movimentos do uso de uma série de recursos para aproximar o universo de Jogo. Todos devem respeitar esta formalidade, caso aplicação da realidade computacional. Esta aproximação é contrário não há Jogo. Formalidade é um fator sempre feita utilizando uma linguagem de programação orientada positivo quando relacionado a elementos de a objetos (Self [11]), cuja concepção peculiar e avançada computação. Um sistema de desenvolvimento deve permite a implementação quase sem esforço destes oferecer este "mundo". Obviamente, para que seja recursos. O conceito de programa é diluído num ambiente respeitada a ilusão de Jogo este mundo deve ser tão Self, o que existe é somente um conjunto de objetos que fechado quanto possível e limitar o número de exibe uma dinâmica entre si. Este comportamento é que elementos estranhos à dinâmica do desenvolvimento. traduz em operações e processamentos. Self apresenta também um ambiente de desenvolvimento gráfico [2] que • O Jogo tem uma natureza própria, independente da reforça o conceito de objetos concretos e acessíveis, consciência daqueles que jogam. O sujeito do Jogo permitindo que a programação seja gráfica e textual, não são os jogadores, porém o Jogo, através dos que dependendo da conveniência do momento. Isto abre uma jogam, simplesmente ganha representação. Assim série de possibilidades com relação ao desenvolvimento de como o Jogo, o resultado do desenvolvimento não sistemas, os elementos computacionais podem ser pode estar submetido aos caprichos dos projetistas. encapsulados em termos de elementos comuns ao domínio Isto significa que as especificações de um projeto de especialização do usuário, de forma a facilitar a sua fazem parte das especificações do ambiente do Jogo compreensão e uso. Isto pode ser reforçado graficamente, de desenvolvimento, de forma a limitar e direcionar as de forma a tornar o desenvolvimento mais agradável e ações do(s) projetista(s) rumo ao objetivo comum. rápido para o usuário. O segundo pilar da metodologia é o rápido possível as informações e conseqüências • Se considerarmos o significado da palavra Jogo, freqüentemente associamos a idéia de conjunto de objetos e movimentos entre eles. Da mesma forma, • O atrativo do Jogo, a fascinação que exerce, reside no sistemas digitais podem ser entendidos como objetos fato de que o Jogo se assenhoreia do jogador. Da que apresentam uma dinâmica muito específica entre mesma forma o ambiente de desenvolvimento deve si. O Jogo, por outro lado, deve representar uma cativar o projetista de forma a mantê-lo no "jogo", ordem, na qual acontece os movimentos, da mesma desempenhando as suas funções até que o objetivo forma com que a dinâmica do sistema traduz um Figura 2 Exemplo de uma descrição de hardware onde representações gráficas e textuais (Self-HDL) se misturam.
• Finalmente, cada jogo coloca uma tarefa ao homem • Um dos atrativos lúdicos de um Jogo é a sua leveza, que o joga. Portanto, cabe ao sistema de ou seja, os movimentos do jogo não devem exigir desenvolvimento colocar este objetivo ao projetista e esforço. Isto convida o jogador a explorar reforçá-lo em cada momento que for possível, para possibilidades e o mantém em foco no jogar. Este é que o mesmo nunca seja perdido ou disperso. um ponto essencial da metodologia, a inexistência de esforços. Cada movimento, traduzida por uma 5. IMPLEMENTAÇÃO DO SISTEMA DO
determinada ação no processo de desenvolvimento, deve aludir a falta de dificuldade. Ou seja, cada ação Podemos então delinear algumas características que são deve ser para o projetista simples e imediata, fundamentais para a metodologia orientada ao projetista: o permitindo que o mesmo permaneça centrado na sistema deve exibir um nível de integração jamais visto tarefa de desenvolvimento. Obviamente, esta leveza nos frameworks convencionais; ele deve ser interativo e não precisa ter um caráter real, apenas uma alusão a interpretado, ou pelo menos interagir com o usuário como falta de esforços, assim como num jogo de monopólio se assim fosse; estar voltado ao campo de aplicação; e pode-se comprar/construir um conjunto industrial finalmente, deve lançar mão de todos os recursos baseados apenas no resultado de um dado. disponíveis para manter a atenção do projetista no objeto do seu trabalho. Veremos a seguir como podemos • Um outro atrativo do Jogo é o caráter lúdico da implementar tais características de forma eficiente. competição, onde o vaivém dos movimentos, livre de esforços, produz situações e condições as vezes além A integração entre ferramentas, ambiente e usuário é um da previsão dos seus jogadores. O Jogo surpreende. problema bastante complexo. Entretanto, como qualquer Um outro caráter importante da metodologia é reagir outro problema envolvendo complexidade, este também imediatamente às modificações ou movimentos pode ser resolvido adotando-se um modelo de efetuados pelos projetistas de forma a oferecer o mais representação adequado. Este modelo é oferecido pela linguagem Self. O uso de uma linguagem especial para principal da metodologia é o objeto "Comp", se implementação de um framework de integração não é uma compararmos com outras HDLs este seria equivalente ao idéia nova, podemos citar o SKILL da Cadence [1]. "Entity" do VHDL ou "Module" do Verilog. Podemos aproveitar as facilidades de desenvolvimento e Evidentemente na metodologia este objeto tem um escopo trabalho com objetos do Self para promover a integração muito maior que nestas HDLs. Comp pode ter a sua do sistema. Self é uma linguagem de alto nível que possui descrição feita em termos funcionais ou estruturais, como uma concepção da orientação a objetos muito peculiar que pode ser visto na Figura 2. Funcionalmente esta descrição a torna também muito simples. O fato de ser baseada em pode ser feita de várias formas diferentes: diagramas de protótipos e possuir tipos dinâmicos também contribuem estado, petri-nets, modelos simbólicos e textuais diversos, muito com essa simplicidade. Todos os elementos em Self sendo a Self-HDL a descrição originalmente desenvolvida. são objetos que podem ser acessados, testados, copiados, etc, mesmo durante a execução de um programa. Isto nos A descrição estrutural consiste numa interconexão de remete a segunda característica, a interatividade, num outros objetos Comp, com o auxílio dos objetos Node. No programa em Self um objeto pode ser modificado mesmo processo de simulação, estes objetos tem a função de quando o mesmo está sendo usado por um programa. É propagação de eventos entre os diversos componentes do como se um mecânico pudesse mudar as características de sistema. Os Nodes herdam o seu modelo de sinal de uma engrenagem enquanto o motor estivesse em objetos especiais implementados para tal. Como em Self funcionamento. Esta característica é fundamental na mesmo a herança pode ser atribuída dinamicamente, os implementação da metodologia, pois os objetos podem ser "parents" do Node podem ser modificados para refletir o concebidos como implementações reais das primitivas de modelo de sinal que for mais conveniente. Atualmente, o desenvolvimento, exibindo instantaneamente a sua sistema está sendo implementado com um modelo simples funcionalidade no instante em que forem instanciados, de quatro valores (0,1,-,X), mas futuramente esperamos assim como um componente real é usado numa bancada de que esteja disponível um modelo compatível com o padrão teste. Para funcionar como bancada também é preciso que IEEE 1164-1993. Evidentemente, para que existam o sistema ofereça um mecanismo de simulação interativa conexões é necessário que existam Ports de entrada e de que tenha características mais próximas a emulação do que saída. Todos os Comps possuem Ports de entrada e de simulação propriamente dita. Em [7] é mostrado que uma saída, as quantidades variam com a funcionalidade do simulação interpretada pode ser quase tão eficiente quanto uma compilada, apesar que o exemplo se referir a simulação lógica podemos facilmente estender o conceito A avaliação do estado de um componente é feita através para simulação funcional hierárquica com resultados do envio da mensagem step para o mesmo. Independente semelhantes. Finalmente, para que seja criada uma ilusão do tipo de descrição (funcional/estrutural), a mensagem mais perfeita desta realidade cibernética de inicia o cálculo das saídas em função das entradas desenvolvimento, uma grande quantidade de recursos correntes. No caso de uma descrição funcional, isto é feito gráficos devem ser utilizados. Em [2] é apresentada uma seguindo diretamente o procedimento especificado pela implementação gráfica para Self que mantém a descrição; no caso estrutural, uma lista de scheduling programação focalizada nos objetos. Mais uma vez este coordenará seletivamente o envio de novas mensagens conceito por ser estendido para o domínio de aplicação de step para os sub-componentes da descrição. A cada forma a criar o "mundo virtual" de desenvolvimento, saída computada e modificada um novo evento será sugerido quando falamos do conceito de Jogo. gerado e acrescentado a lista de scheduling, Figura 3. Este esquema é tipicamente event-driven, entretanto adotamos Como exemplo, vejamos como são implementados alguns otimizações sugeridas em [7] que nos permitem resultados objetos fundamentais da metodologia. Num processo de interessantes. Um Comp que não seja alterado por um desenvolvimento de hardware, é natural e desejável que o determinado evento não precisa ser incluído na lista de projetista pense também em termos de hardware. Isto é scheduling, isto permite por exemplo que simulações cycle necessário pois quanto mais próximo do objetivo final do based possam ser feitas usando o mesmo mecanismo. processo mais simples são as ferramentas de auxílio e Customizando os objetos Comp e indicando que estes são síntese necessárias. Seguindo este princípio, o objeto1 sensíveis somente a certos Ports ("clocks"), podemos facilmente transformar uma simulação event-driven em cycle based, ou mesmo combinar as duas num dado 1 Faremos todas as descrições em termos de objetos, uma vez que em Self não existe o conceito de classes. Objetos podem herdar de outros objetos (herança múltipla), e são especiais mantidos especialmente para este fim, são os usados/criados a partir de cópias de outros objetos Até o momento, a implementação não parece muito diferente de outros sistemas. Entretanto como dissemos, a grande diferença encontra-se na integração de ferramentas e na interação com o usuário. Suponha por exemplo, o fluxo ideal de trabalho na metodologia DO e como ele opera com os objetos apresentados. Suponha que estejamos trabalhando num projeto usando uma das descrições de alto nível disponíveis, após as verificações iniciais (simulações) é necessário uma verificação mais efetiva (formal) para que seja possível passar para as próximas etapas de desenvolvimento. Isto é feito simplesmente enviando um mensagem conveniente ao objeto Figura 3 Esquema de scheduling de avaliação de
Comp. Por exemplo, checkProp. Esta mensagem pode consistir de uma verificação de propriedades previamente configuradas no início do projeto. Uma vez A interatividade e característica de imersão apontada na confirmada a consistência do modelo, passaríamos a fase seção 4 através do conceito de Jogo, é obtida inicialmente de síntese de alto nível, onde baseados na descrição através da implementação e manipulação de ícones dos funcional seria gerado um modelo arquitetural (estrutural) elementos de projeto. Os elementos gráficos têm uma do componente. Mais uma vez isto seria resultado de uma importância muito grande nesta metodologia, não só como simples mensagem, por exemplo: archGen. O modelo elementos de organização como foi apontado gerado não iria criar um outro objeto, mas sim acrescentar anteriormente, mas como elemento essencial para a ao Comp original uma nova descrição, desta vez criação da "realidade virtual" de projeto. Por exemplo, estrutural. Comp pode ter quantas descrições se fizerem através do mesmo ícone o projetista poderia interagir com necessárias, a descrição recém gerada passaria a ser a Comp durante uma simulação. Usando objetos especiais, descrição corrente e a tomada como base seria a descrição os Observers, que o projetista poderia conectar-se aos anterior. Uma vez exercitada a nova descrição (simulada), Ports de um componente e observar o resultado da uma nova etapa de verificação formal seria necessária, simulação a medida em que esta se desenrola. desta vez comparando as duas implementações, isto seria Obviamente, um Observer poderia ser customizado de através da mensagem verify. Poderíamos seguir forma a formatar o(s) ponto(s) de medição de acordo com sucessivamente estes passos até obter uma descrição do as conveniências do projetista, e assim parecer um Comp original em termos de Comps em nível RTL. Neste instrumento de medida, painel de controle e etc. Isto ponto poderíamos facilmente obter uma descrição HDL também é muito interessante, pois permite ao projetista convencional através de uma mensagem como VHDLGen, formatar e mascarar a implementação de um dado sistema ou VerilogGen, que se encarregaria de gerar uma e permitir apresentações de simulações reais para equipes descrição HDL que pode ser sintetizada do componente menos ligadas aos detalhes de implementação do hardware, como: equipes de desenvolvimento de software, Um ponto importante a ser lembrado é que implementando o framework em Self, é possível uma funcionalidade 6. CONCLUSÃO
exatamente da forma com que foi proposta. Cada uma destas mensagens pode ser simplesmente um botão no Apresentamos neste artigo os conceitos principais de uma ícone de representação de Comp, e que só estaria Metodologia Orientada ao Projetista para o disponível quando e se as condições necessárias ao seu desenvolvimento de sistemas digitais. Vimos que funcionamento estiverem também disponíveis. Não seriam conceitualmente esta metodologia pode ser estendida a necessários conceitos como arquivos, nomes de arquivos, outras áreas de conhecimento, porém o objetivo principal diretórios, sintaxe de comandos e etc, pois tudo estaria deste trabalho é o desenvolvimento de um framework para acessível e organizado automaticamente através do ícone desenvolvimento de sistemas em nível RTL, arquitetural e superior. Foi mostrado como alguns pontos chaves da metodologia estão sendo implementados utilizando a linguagem Self. O trabalho encontra-se nas fases iniciais de desenvolvimento, onde se pretende especificar e implementar um conjunto de objetos de hardware que caracterize o nível RTL de descrição, e o mecanismo básico de inferência para a simulação. Ambas as implementações terão contrapartida textual e gráfica e visam principalmente manter o foco de atenção do projetista nos objetos de hardware, sem se preocupar com a interface. Futuramente planejamos a implementação de um gerador de código HDL padrão (VHDL/Verilog) para propósitos de síntese automática, e também a inclusão de outras representações de auto nível visando talvés high-level synthesis. 7. REFERÊNCIAS
[1] CADENCE. SKILL Language Reference Manual. Cadence Design Systems, Inc, June 1989. [2] CHANG, B.-W., UNGAR, D., AND SMITH, R. B. Visual Object-Oriented Programming. Prentice-Hall, 1995, chapter: Getting Close to Objects: Object-Focused Programming Environments, pp. 185-198. [3] FLAKE, P. L., DAVIDMANN, S. J., AND KELF, D. J. Measuring design languages for system-on-chip design. Tech. Rep., Co-Design Automation, Inc., San Jose, CA 95113-1295, 2000. [4] GADAMER, H.-G. Verdade e Método: Traços fundamentais de uma hermenêutica filosófica. Editora Vozes, 1999. [5] ITRS. International Technology Roadmap for Semiconductors - design - 2001 Edition. http://public.itrs.net/Files/2001ITRS/Home.htm, 2001. [6] KUHN, T., AND ROSENSTIEL, W. Java based object oriented hardware specification and synthesis. In Proceedings of the ASP-DAC 2000. Asia and South Pacific Design Automation Conference, 2000, pp. 579-581. [7] MAURER, P. M. Is compiled simulation really faster than interpreted simulation? In Proceedings of the 9th International Conference on VLSI Design, 1996, pp. 303-306. [8] SHRIVER, B., AND SMITH, B. The Anatomy of a High-Performance Microprocessor: A System Perspective. IEEE Computer Society, 1998. [9] SYNOPSYS, I. System C - Version 2.0 - User's Guide. http://www.systemc.org, 2002. [10] THON, L. E., AND BRODERSEN, R. W. C to silicon compilation. In Proceedings of the 1992 IEEE Custom Integrated Circuits Conference (1992), pp. 11.7.1-11.7.4. [11] UNGAR, D., AND SMITH, R. B. SELF: The power of simplicity. LISP AND SYMBOLIC COMPUTATION: An International Journal. Kluwer Academic Publishers 4, 3 (June 1991).

Source: http://www.iberchip.net/IX/Articles/PAP-046.pdf