PROJETO, SÍNTESE E SIMULAÇÃO DAS INTERFACES DE REUSO DE HARDWARE DO PADRÃO OCP (OPEN CORE PROTOCOL)

Transcrição

1 PROJETO, SÍNTESE E SIMULAÇÃO DAS INTERFACES DE REUSO DE HARDWARE DO PADRÃO OCP (OPEN CORE PROTOCOL) Marcelo S. Porto, Roger E. C. Porto, José Luís A. Güntzel, Luciano V. Agostini Grupo de Arquiteturas e Circuitos Integrados (GACI) Departamento de Informática Universidade Federal de Pelotas (UFPel) Caixa Postal 354 CEP Pelotas/RS Brasil {porto, rogerecp, guntzel, agostini }@ufpel.edu.br RESUMO O crescimento da indústria da microeletrônica torna cada vez mais importante o reuso de blocos de hardware. O padrão OCP (Open Core Protocol) é um padrão de interface para blocos de hardware, que potencializa o reuso destes blocos. Neste artigo são apresentadas as descrições e as validações das interfaces mestre e escravo do padrão OCP. As interfaces foram descritas em VHDL e sintetizadas para FPGAs Altera. A funcionalidade e o protocolo de comunicação das interfaces foram validados através de simulações. Os dados de síntese indicaram que a interface mestre utilizou 28 células lógicas e atingiu uma freqüência de 333,3 MHz, enquanto que a interface escravo utilizou 20 células lógicas e atingiu uma freqüência de 263,16 MHz. Estima-se que o uso destas interfaces em um sistema complexo teria impacto inferior a 1% em termos do uso de células lógicas e nenhum impacto em termos de freqüência de operação. 1. INTRODUCÃO Devido à crescente complexidade no desenvolvimento de Sistemas em Chip (SoCs) e às exigências da indústria no sentido de acelerar a colocação de um produto no mercado (time-to-market), o reuso de blocos de hardware, também chamados de núcleos de propriedade intelectual (IPs) [1], teve um crescimento significativo tanto no meio acadêmico quanto no meio industrial. Esta nova realidade no mundo da microeletrônica mudou a rotina da maioria dos projetistas, que passaram a se preocupar não só em desenvolver um sistema que funcione bem, mas também, em desenvolver um sistema que seja robusto o suficiente para tornar-se reusável. Com isso, surgiu um novo mercado que cresce a cada dia, pois qualquer projetista que desenvolva um IP que funcione e que respeite algum padrão de interface para reuso de hardware pode comercializar este IP para qualquer outro projetista que utilize o mesmo padrão de interface para reuso. O padrão Open Core Protocol OCP [2] é um dos padrões de interface mais utilizados nos projetos baseados em reuso de hardware e tende a se tornar um padrão de fato para a indústria. Sua maior vantagem em relação aos demais padrões de interface para reuso é o fato de ser um padrão aberto e de uso gratuito. Este artigo tem como objetivo apresentar experimentos realizados com o padrão OCP e os impactos causados por seu uso em projetos de SoCs. O padrão OCP pode transformar um bloco de hardware em um IP reusável, podendo, assim, ser inserido em qualquer projeto de SoC que seja compatível com o padrão OCP. Neste trabalho, são apresentadas as interfaces mestre e escravo do padrão OCP [3], bem como a sua descrição utilizando a linguagem de descrição de hardware VHDL [4]. Para desenvolver e validar os experimentos propostos neste trabalho foi utilizado o ambiente Quartus II da Altera [5]. Através da síntese das descrições das interfaces foi possível obter resultados de desempenho e uso de recursos. A síntese foi direcionada para um dispositivo lógico programável do tipo FPGA. Os resultados de síntese, que serão apresentados em detalhes neste trabalho, indicaram que as interfaces geram um impacto muito pequeno no total de recursos oferecidos pelo dispositivo. Na seção dois deste artigo está apresentada uma introdução da interface de reuso OCP, com a apresentação de seus sinais básicos e de suas características de comunicação. Na seção três são detalhadas as descrições das interfaces OCP mestre e escravo, juntamente com alguns resultados de síntese. Na seção 4 estão apresentados os métodos de validação utilizados e detalhadas algumas operações de leitura e escrita com a utilização das interfaces OCP. Na seção cinco, são apresentados os resultados de síntese e alguns resultados comparativos, na seção seis, são apresentadas propostas de trabalhos futuros e, na seção sete, são apresentadas as conclusões do artigo. 1

2 2. A INTERFACE OCP O OCP é um padrão de interface de reuso de hardware totalmente aberto e gratuito, ou seja, pode ser usado por qualquer projetista que queira desenvolver um IP reusável [2] sem nenhum custo. Este padrão consiste em um conjunto de sinais e protocolos de comunicação que têm como objetivo padronizar a comunicação entre blocos IPs que, quando utilizados em um SoC, podem reduzir significativamente o tempo de projetos do sistema. O padrão OCP define uma interface ponto a ponto entre duas entidades de comunicação denominadas mestre e escravo [3]. A interface mestre é responsável pelo controle da comunicação e somente ela pode iniciar ou parar uma troca de informações. A interface escravo, por sua vez, responde aos comandos da interface mestre, realizando as operações correspondentes a sua solicitação e enviando ou recebendo dados. Uma característica importante e favorável ao padrão OCP é o fato de um IP com interface OCP pode ser, ao mesmo tempo, mestre e escravo [3]. Outros padrões, como o VCI [6], por exemplo, não possuem esta característica de forma explícita. Esta característica pode ser bastante útil para diversas aplicações. A funcionalidade de cada IP é que determina a necessidade deste IP ser mestre, ser escravo ou ser mestre e escravo. Para que um IP esteja compatível com o padrão OCP é necessário que ele siga um conjunto mínimo de regras, como possuir, no mínimo, os sinais definidos como basic signals [3], mantendo sempre o protocolo definido sobre estes sinais e obedecendo a temporização dos sinais estabelecido pelo padrão [3]. A tabela 1 apresenta os basic signals definidos pelo padrão OCP. Na tabela 1 todos os sinais que começam com M são provenientes da interface OCP mestre, já os sinais que começam com S são os sinais enviados da interface OCP escravo. Os sinais MAddr, MCmd, MData, SCmdAccept, SData e SResp são usados pelo protocolo de handshake presente nas duas interfaces OCP. O correto acionamento destes sinais, respeitando as regras do protocolo, permitirá a troca de informações entre as duas interfaces. O sinal Clk é comum a ambas interfaces e é um provido pelo sistema no qual as interfaces estão inseridas. Este sinal é responsável pela sincronização da comunicação entre as interfaces OCP mestre e OCP escravo. Tabela 1 - Sinais básicos do padrão OCP Nome Tamanho (bits) Função Clk 1 Clock OCP MAddr 1 32 Endereço de transferência MCmd 3 Comando de transferência MData 8/16/32/64/128 Dado de escrita SCmdAccept 1 Aceita transferência SData 8/16/32/64/128 Dado de leitura SResp 2 Resposta do escravo A fig. 1 ilustra uma comunicação simples entre dois blocos utilizando uma interface OCP com os seus sinais básicos. Fig. 1. Comunicação simples entre interfaces OCP mestre e escravo A comunicação sempre começa com a borda de subida do clock e com a ativação, por parte do mestre, do sinal MCmd, que pode conter uma solicitação de leitura ou de escrita [3]. No entanto, a comunicação depende também da resposta do escravo perante a solicitação do mestre. Caso o escravo esteja apto para a comunicação ele ativa o sinal ScmdAccept, levando-o para nível alto. Ao perceber a resposta do escravo, o mestre está apto, novamente, a solicitar uma comunicação ou repetir a solicitação anterior, caso o escravo não tenha aceitado seu pedido no ciclo anterior [3]. O conjunto básico de sinais do padrão OCP também define mais três barramentos, o MData e o SData para o envio de dados e o MAddr para o envio de endereço de leitura, além do sinal SResp que o escravo envia para o mestre para indicar que o pedido de leitura resultou em um dado válido. 2

3 3. DESCRIÇÃO VHDL DAS INTERFACES As interfaces OCP, neste trabalho, foram descritas em VHDL [4], visando explorar a sua flexibilidade no desenvolvimento de IPs que utilizem esta interface, bem como no desenvolvimento de experimentos com estes IPs e estas interfaces. O ambiente de Quartus II da Altera [5] foi utilizado para descrever as interfaces em VHDL, para sintetizá-las e para validá-las. A interface escravo foi modelada através de uma máquina de estados finitos (FSM), que está apresentada na fig. 2. Esta FSM é bastante simples e possui apenas três estados: Idle (ocioso), Write (escrita) e Read (leitura). A descrição VHDL da interface escravo é formada por dois processos concorrentes, um responsável pela mudança de estado e outro responsável pela geração dos sinais de saída. Fig. 2. Máquina de estados para a interface escravo A cada borda de subida de clock a interface escravo analisa suas entradas Reset e MCmd. O sinal Reset foi omitido na fig. 2, com o intuito de simplificá-la. O sinal Reset é assíncrono e quando está ativo mantém a FSM da interface escravo no estado Idle, ou seja, o escravo pára o que estiver fazendo e fica esperando uma desativação do sinal Reset e, posteriormente, aguarda neste estado até que o mestre solicite, através do sinal MCmd, uma nova operação de leitura ou escrita. Quando o mestre, através do sinal MCmd, solicita uma escrita, o escravo passa para o estado Write e indica, com o sinal SCmdAccept, que aceita ou não a requisição de escrita. O escravo também captura o dado e o endereço contidos nos barramentos MData e MAddr, respectivamente, para executar a operação de escrita interna. O sinal SResp retorna NULL pois se trata de um operação de escrita. No caso de uma solicitação de leitura, o procedimento é praticamente o mesmo, mas neste caso o escravo passa para o estado Read, busca o endereço no barramento MAddr e disponibiliza o dado para o mestre no barramento SData juntamente com a ativação do sinal SResp = DVA, que indica para o mestre que o dado requerido é válido. O sinal SCmdAccept, quando ativo, é usado para o escravo indicar para o mestre que está apto para uma operação de escrita ou leitura. Se este sinal estiver desativado, o escravo está indicando ao mestre que não pode atender a uma solicitação do mestre naquele ciclo de clock. A interface mestre também foi modelada através de uma máquina de estados finitos. No entanto, como a interface mestre é responsável pela ativação do processo de comunicação, é necessário considerar as respostas do escravo perante as requisições que foram realizadas e repetir a requisição no próximo ciclo, caso o escravo não tenha atendido à solicitação no atual ciclo de clock. Quando o mestre solicita uma leitura, por exemplo, a sua FSM passa para o estado Read, indicando que o mestre está fazendo uma solicitação de leitura através do sinal MCmd. Simultaneamente, o mestre disponibiliza o endereço de leitura no barramento MAddr. A FSM da interface mestre permanece no estado Read até que a interface escravo confirme que está apto para atender a solicitação, ou seja, quando o sinal SCmdAccept está ativo. Na fig. 3, está apresentada a FSM desenvolvida na descrição da interface mestre. Para a operação de escrita o procedimento é praticamente o mesmo, a FSM passa para o estado Write, indicando que o mestre deseja uma operação de escrita através do sinal MCmd. Simultaneamente, o mestre disponibiliza o endereço para a escrita no barramento MAddr e o dado no barramento MData. Da mesma forma que para a operação de leitura, a FSM da interface mestre permanece no estado Write até que a interface escravo confirme que está apta para atender o pedido de comunicação. A interface mestre possui uma condição de permanência no estado atual caso não exista uma resposta favorável do escravo para a solicitação do mestre. A fig. 3 mostra a utilização do sinal MCmd_tmp, que não havia sido citado anteriormente, ele é um sinal externo à interface mestre e serve para indicar um pedido de leitura ou escrita que está sendo realizado pelo IP conectado ao mestre. Este pedido será encaminhado para o IP conectado à interface escravo através da interface mestre. A comunicação entre os dois blocos de hardware será transparente para estes blocos, mantendo a sensação de conexão ponto a ponto direta entre eles. Todo o processo de controle da comunicação é de responsabilidade das interfaces OCP mestre e escravo. 3

4 interface como um componente discreto, simulando sinais em suas entradas e analisando as respostas que são enviadas para suas saídas. Esta última opção foi desenvolvida e será apresentada neste artigo. A primeira opção está sendo desenvolvida, mas ainda não foi finalizada. Nos experimentos apresentados a seguir, o período de clock utilizado na simulação foi de 10ns. Fig. 3. Máquina de estados para a interface mestre Na fig. 2 e na fig. 3, com as FSM das interfaces OCP escravo e mestre, não são apresentados os barramentos de dados e endereços, MData e Maddr, pois estes valores não são utilizados pelo processo responsável pela mudança de estado. 4. VALIDAÇÃO DAS INTERFACES Para validar uma interface de reuso padronizada a melhor alternativa é utilizar as ferramentas que os grupos desenvolvedores dos padrões disponibilizam para tal fim. O problema é que estas ferramentas não estão disponíveis em nossa instituição por conta do elevado custo de suas licensas. Deste modo, soluções alternativas tiveram que ser desenvolvidas para verificar se a interface estava funcionando corretamente e se o seu protocolo estava correto. Uma das alternativas foi desenvolver blocos de hardware que servem como IPs que se comunicam através da interface e, então, analisar os resultados obtidos. Outra possibilidade é considerar o resultado obtido na síntese da 4.1 Interface Escravo Para a validação da interface escravo, esta interface foi estimulada com entradas equivalentes àquelas geradas por uma interface mestre, fazendo requisições de leitura e escrita e gerando dados e endereços aleatórios. Os dados e endereços gerados para estes testes são totalmente irrelevantes, pois o objetivo principal na validação é verificar o correto funcionamento da interface e de seu protocolo. A fig. 4 apresenta um trecho da simulação desenvolvida para verificar o correto funcionamento da interface. Na fig. 4 podem ser observados os resultados obtidos com os pedidos de leitura e escrita simulados nas entradas da interface escravo, através da análise das formas de onda de entrada e saída. No instante inicial da simulação apresentada na fig. 4, pode ser observado que o sinal Reset_n está em nível baixo, ou seja, ativo. Isto faz com que a interface escravo fique em estado Idle, colocando todas as suas saídas em zero. Na segunda borda ascendente de clock, identificada com a letra b na fig. 4, o sinal Reset_n está desativado e o escravo está recebendo na entrada MCmd, o valor 000, o que indica que o mestre não está solicitando nenhuma operação de leitura ou escrita e, por isso, a interface escravo mantém suas saídas em zero. a b c d e f g Fig. 4. Formas de onda da simulação da interface escravo no ambiente Quartus II da Altera 4

5 Somente na terceira borda ascendente do clock, identificada pela letra c na fig. 4, é que o mestre indica, através da mudança do sinal MCmd de 000 para 001, que deseja uma operação de escrita. No mesmo ciclo o escravo responde que aceita a operação, ativando o sinal SCmdAccept. Simultaneamente, o escravo ativa o sinal WE, que não havia sido mencionado anteriormente. Este sinal não faz parte da interface externa do escravo, sendo apenas um sinal interno que indica, quando ativado (WE = 1), que está acontecendo uma escrita nos módulos do escravo e, quando desativado (WE = 0), que está acontecendo uma leitura. Na quarta borda ascendente de clock, identificada pela letra d na fig. 4, o escravo não recebe nenhuma solicitação do mestre e volta para o estado Idle. Na quinta borda ascendente de clock, identificada pela letra e na fig. 4, o escravo recebe uma solicitação de leitura com o sinal MCmd = 010. Imediatamente, o escravo responde que está apto, com a ativação do sinal SCmdAccept e também atribui o valor 01 ao sinal SResp, o que indica que o dado é válido e está disponível no barramento SData. Na sexta e na sétima bordas ascendentes de clock, identificadas pelas letras f e g na fig. 4, o sinal MCmd volta para o valor 000, indicando que o mestre não deseja realizar nenhuma comunicação e, então, a interface escravo volta para o estado Idle.Não foram apresentados, na fig. 4, os barramentos do mestre, MAddr e MData, e o barramento do escravo SData, pois estes valores são irrelevantes para a validação do protocolo de comunicação da interface. 4.2 Interface Mestre Na interface mestre, a estratégia utilizada para a validação foi a mesma utilizada na interface escravo. A interface foi estimulada com entradas equivalentes àquelas geradas por uma interface escravo. Assim, foi possível analisar seu comportamento, solicitando pedidos de leitura e escrita e avaliando as respostas do escravo. Nesta descrição da interface mestre, foi adicionada uma entrada, MCmd_tmp, que simula os pedidos de leitura e escrita feitos pelo IP que está anexado à interface mestre. Na fig. 5 está apresentado um trecho da simulação da interface mestre. Nos dois primeiros ciclos, indicados pelas letras a e b na fig. 5, a interface mestre, permanece em estado Idle. Neste estado todas as suas saídas são mantidas em zero e todas as entradas provenientes da interface escravo também permanecem em zero. No terceiro ciclo, representado pela letra c, o sinal MCmd é levado para o valor 001, o que indica o desejo do mestre de realizar uma operação de escrita. Como pode ser percebido o sinal MCmd_tmp indica uma solicitação de escrita antes da terceira borda ascendente de clock, no entanto, seu pedido só será atendido no momento da borda de subida, como indica o padrão OCP [3]. Ao mesmo tempo que indica a solicitação de escrita, o mestre também disponibiliza o endereço e o dado para a operação. O escravo indica que aceita a operação e ativa o sinal SCmdAccept. No quarto ciclo, indicado pela letra d, o mestre não faz nenhuma solicitação e entra em estado Idle. Logo após, ainda no quarto ciclo, o IP solicita ao mestre uma operação de leitura (MCmd_tmp = 010 ). Então, no quinto ciclo (indicado pela letra e na fig. 5), o mestre leva a sua saída MCmd para 010, indicando uma solicitação de leitura e, simultaneamente, disponibiliza o endereço no barramento MAdd. Neste caso, foi simulada uma impossibilidade, por parte do escravo, de atender o pedido do mestre, ilustrado pela não ativação do sinal SCmdAccept. a b c d e f g Fig. 5. Formas de onda da simulação da interface mestre no ambiente Quartus II da Altera 5

6 A reação do mestre é manter o pedido de leitura e o endereço, até que o escravo esteja apto para realizar a transação. Isto acontece no sexto ciclo, indicado pela letra f na fig. 5, quando o escravo ativa o sinal SCmdAccept (para indicar que está apto) e também disponibiliza o dado no barramento SData e ativa o sinal SResp para indicar que o dado é válido. No sétiomo ciclo, indicado pela letra g, na fig. 5, o IP não solicita nenhuma operação e o mestre volta para o estado Idle. 5. RESULTADOS DE SÍNTESE Na descrição em VHDL das máquinas de estados finitos que constituem a interface escravo foram utilizadas setenta e oito linhas de código. Para a descrição da interface mestre foram utilizadas oitenta e nove linhas de código. A tabela 2 ilustra os resultados obtidos para a síntese, deste código fonte, dimensionada para o FPGA EPF10K130EQC240-1 da família FLEX 10KE da Altera. Blocos de Hardware Tabela 2 Resultados de síntese Células Lógicas Freqüência (MHz) Período (ns) OCP Escravo ,1 3,8 OCP Mestre ,3 3 Para a síntese da interface escravo, menos de 1% das células lógicas e apenas 19% dos pinos disponíveis foram utilizados. Na descrição da interface mestre, também foram utilizados menos de 1% das células lógicas com uma utilização de 27% dos pinos disponíveis. Como pode ser percebido pela tabela 1, a freqüência máxima de operação da interface mestre foi superior a freqüência máxima de operação da interface escravo, no entanto, a interface mestre consumiu um número maior de células lógicas do dispositivo. 5.1 Resultados Comparativos Este trabalho apresenta alguns resultados comparativos entre o desenvolvimento das interfaces OCP e o desenvolvimento de interfaces VCI [6], mais especificamente, as interfaces Peripherical VCI (PVCI) [7] e Basic VCI (BVCI) [8]. As interfaces VCI estão sendo desenvolvidas em trabalhos paralelos. Além disso, os resultados de síntese das interfaces OCP são comparados aos resultados de síntese de uma arquitetura de cálculo da DCT 2-D [9] e de uma arquitetura para compressão JPEG [9]. Estes blocos de hardware são candidatos a receberem as interfaces OCP em experimentos futuros. Os dados comparativos estão apresentados na tabela 3. Tabela 3 Resultados comparativos de síntese Blocos de Hardware Células Lógicas Freqüência (MHz) Período (ns) OCP Escravo ,1 3,8 OCP Mestre ,3 3 PVCI Alvo 8 333,3 3 PVCI Iniciadora ,9 8,2 BVCI Alvo ,9 6,1 BVCI Iniciadora ,9 5,3 DCT 2-D ,1 33,2 Compressor JPEG , As comparações com as interfaces VCI, indicam que o padrão OCP possui uma complexidade implementação intermediaria entre as duas interfaces, PVCI e BVCI, do padrão VCI [6]. Na comparação com a interface PVCI podemos notar que as duas interfaces as interfaces tem um consumo muito pequeno de células lógicas, e podem operar a uma freqüência máxima de operação bastante elevada. No entanto, na comparação entre as interfaces OCP e BVCI, podemos notar um consumo maior de células lógicas por parte da interface BVCI. Isto se explica devido ao fato de que a interface BVCI possui um protocolo mais completo, que estabelece uma comunicação maior, entre iniciador e alvo, antes da execução de uma transação [7]. Este maior consumo de células lógicas, por parte da interface BVCI, também é causado pela utilização de dois barramentos independentes para requisição e resposta. Isto aumenta o grau de complexidade da interface, fazendo com que sua implementação necessite de um maior número de células lógicas e também que sua freqüência máxima de operação seja inferior a freqüência máxima de operação das interfaces OCP. A partir da tabela 3 é possível notar que a utilização de células lógicas por parte das interfaces OCP é insignificante se comparado ao consumo de células lógicas da DCT 2-D e do compressor JPEG, que são candidatos a utilizarem estas interfaces. A diferença de consumo de células lógicas é da ordem de 182 vezes menor se comparado ao consumo de células lógicas do compressor JPEG. Do ponto de vista da freqüência máxima de operação, é possível perceber que as interfaces OCP operam em velocidades muito superiores às velocidades da DCT 2-D e do compressor JEPG. Se comparada a freqüência máxima de operação do compressor JPEG, a interface OCP mestre, pode operar a uma freqüência aproximadamente 10 vezes maior, e a interface escravo, a uma freqüência aproximadamente 8 vezes maior. Estes 6

7 resultados indicam que não haveria perdas na freqüência máxima de operação destes blocos de hardware com a utilização das interfaces OCP. 6. TRABALHOS FUTUROS Como trabalhos futuros pretende-se concluir a validação da interface, através de novos experimentos com blocos auxiliares. Este trabalho está em andamento e dará uma idéia mais precisa sobre a freqüência de operação que a interface suporta. Em um segundo momento, pretendemos realizar um estudo de caso em um compressor de imagens JPEG [9], já citado anteriormente, estabelecendo uma tabela de resultados comparativos, tanto de desempenho quanto de uso de recursos, para os módulos do compressor JPEG antes e depois do uso da interface OCP. Para este trabalho, é importante salientar em que nível será aplicada a interface de reuso. Se aplicarmos a interface OCP sobre o projeto completo do compressor, teremos um compressor de imagens JPEG reusável e compatível com o padrão OCP. O acréscimo no consumo de recursos para gerar o compressor reusável seria, neste caso, igual aos recursos utilizados por uma interface mestre ou por uma interface escravo, dependendo da necessidade de se ter o compressor como um bloco mestre ou como um bloco escravo dentro aplicação. Outra possibilidade seria diminuir a granularidade. No entanto, se aplicarmos a interface OCP em cada um dos blocos do compressor, como por exemplo, a DCT - 2D, Quantizador e Buffer Zigue Zague, como ilustra a fig. 6, teremos quatro aplicações de interface pra estabelecer a comunicação ponto-a-ponto entre os blocos. Isto causaria um consumo maior de células lógicas por parte da interface de reuso, no entanto, ainda seria um consumo muito pequeno se comparado ao consumo total dos blocos, com a vantagem de tornar cada bloco do compressor JPEG reusável, podendo ser substituído por outro bloco reusável que também utilize o padrão OCP. Fig. 6. Aplicação das interfaces OCP nos blocos do compressor JPEG chegando a conclusões sobre as qualidades e deficiências de cada padrão. O padrão VCI está sendo investigado em trabalhos paralelos [9]. 7. CONCLUSÕES Este trabalho teve como objetivo principal desenvolver, sintetizar e validar as interfaces de reuso de hardware do padrão OCP. Com as arquiteturas desenvolvidas, foi possível identificar com clareza toda a funcionalidade do padrão, demonstrando que a utilização da interface OCP é uma maneira prática e fácil de desenvolver blocos de hardware reusáveis. Um dos resultados mais importantes obtidos com este trabalho é a constatação de que a utilização da interface OCP não tem uma influência significativa no que diz respeito ao consumo de recursos. Para as sínteses realizadas para o FPGA EPF10K130EQC240-1, a interface OCP mestre utilizou apenas 28 células lógicas e a interface OCP escravo utilizou 20 células lógicas. Nos dois casos, são utilizados menos de 1% dos recursos disponíveis no dispositivo. Esta questão é muito importante, pois um consumo excessivo de recursos poderia inviabilizar a utilização da interface. Por outro lado, a interface OCP mestre, atingiu uma freqüência máxima de operação de 333,3 MHz. Já a interface escravo, alcançou uma freqüência máxima de operação de 256,16 MHz. Nos dois casos, a freqüência máxima alcançada é muito superior as freqüências de operação dos blocos do compressor JPEG ilustrados na tabela 3, indicando que não haverá impacto em termos de freqüência de operação com o uso destas interfaces em um bloco de hardware deste nível de complexidade. Outro dado interessante foi a imensa diferença, no consumo de células lógicas, se compararmos as interfaces OCP e um bloco de hardware de complexidade relativamente grande, como o compressor de imagens JPEG. As interfaces OCP possuem um consumo aproximadamente 182 vezes menor que o consumo do compressor JPEG. Além disso, as interfaces OCP podem operar a uma freqüência máxima em torno de 9 vezes maior que a máxima freqüência de operação do compressor JPEG. Dos resultados obtidos, é possível concluir que os custos adicionais causados pelo uso das interfaces OCP em um bloco de hardware são irrelevantes se considerado o ganho com relação ao tempo necessário para colocar no mercado um componente complexo de hardware, que utiliza blocos reusáveis, com relação a outro que tenha todos os seus blocos desenvolvidos separadamente. Outro trabalho futuro será o desenvolvimento de uma comparação entre o padrão OCP e o padrão VCI, analisando os resultados obtidos com os dois padrões e 7

8 8. REFERÊNCIAS [1] M. Keating e P. Bricaud, Reuse Methodology Manual for System-on-a-Chip Designs, 2ª ed., Kluwer Academic Publishers, EUA, [2] OCP Iternational Partnership. OCP Iternational Partnership: The Complete Socket. < Janeiro [3] OCP Iternational Partnership. Open Core Protocol Specification (Release 1.0) [4] P. Ashenden. The Designer s Guide to VHDL second edition. Morgan Kaufmann Publishers, EUA, [5] Altera Corporation, Altera: The Programmable Solutions Company, < [6] VSIA. On-Chip Bus Development Working Group. Virtual Component Interface Standard (OCB 2.1.0). Março [7] T. Silva, R. Porto, R. Tavares, L. Agostini. Experimentos com a Interface de Reuso PVCI em uma DCT-2D Direcionada para a Compressão JPEG. In: IX WORKSHOP IBERCHIP, 2004, Cartagena de Indias, Colombia. 1 CD. [8] T. Silva, L. Agostini. Experiments with BVCI Interface and with Design of Systems-on-Chip based on Hardware Reuse. In: SIM XIX South Symposium on Microeletronics, 2004, São Miguel das Missões. [9] L. Agostini, Projeto de Arquiteturas Integradas para a Compressão de Imagens JPEG. Dissertação de Mestrado Universidade Federal do Rio Grande do Sul. II. PPGC, Porto Alegre, Brasil,