DESENVOLVIMENTO E VALIDAÇÃO DAS INTERFACES BVCI PARA O
REUSO DE BLOCOS DE HARDWARE
Thaísa Leal da Silva, Roger Endrigo Carvalho Porto, José Luís Güntzel, Luciano Volcan Agostini
Grupo de Arquiteturas e Circuitos Integrados (GACI)
Departamento de Informática – Universidade Federal de Pelotas (UFPel)
Caixa Postal 354 – CEP. 96010-900 – Pelotas/RS – Brasil
{thleal, rogerecp, guntzel, agostini}@ufpel.edu.br
RESUMO
Este trabalho tem como objetivo explorar metodologias de
reuso de blocos de hardware no projeto de sistemas em
chip, a partir de experimentos com a interface BVCI
(Basic Virtual Component Interface). As interfaces BVCI
Iniciadora e Alvo foram descritas em VHDL e sintetizadas
para um FPGA da Altera. Após a síntese, as interfaces
foram validadas através de simulações. O protocolo
handshake também foi validado através da conexão entre
as interfaces. A interface BVCI Iniciadora utilizou 50
células lógicas e atingiu uma freqüência de operação de
188,7 MHz, enquanto que a interface BVCI Alvo utilizou
26 células lógicas, atingindo uma freqüência de operação
de 163,9 MHz. Através da comparação destes resultados
aos obtidos na síntese de blocos de hardware candidatos a
utilizarem estas interfaces, foi possível estimar que os
impactos em termos de desempenho e uso de recursos
serão mínimos quando as interfaces BVCI forem
integradas a estes blocos.
1. INTRODUÇÃO
O aumento da capacidade dos circuitos integrados tem
permitido a inclusão de um número crescente de módulos
de hardware em um único dispositivo, gerando maiores
níveis de complexidade na criação desses chips. Estes
circuitos integrados de alta escala de integração, com
funcionalidades avançadas e com projetos com elevada
complexidade, são chamados de sistemas em chip
(Systems-on-Chip) ou SoC’s. Os SoC’s visam
proporcionar uma integração mais eficaz de componentes
complexos no interior dos circuitos integrados, com o
objetivo de gerar sistemas que utilizem menor área,
possuam um maior poder de processamento e possuam
um reduzido consumo de energia. Como SoC’s são
sistemas complexos, eles demandam uma grande
quantidade de tempo para serem projetados, fato que se
contrapõe às exigências de mercado.
Em função disso, tornou-se necessária a adoção de uma
nova metodologia para o desenvolvimento de SoC’s
enfatizando menor tempo de projeto e garantindo a
permanência da qualidade em termos de área, desempenho
e consumo. A reutilização de blocos de hardware através
do uso de interfaces de comunicação padronizadas e a
geração de núcleos de propriedade intelectual (IP) em
escala industrial, contribuíram para solucionar esse
problema.
Para a indústria de microeletrônica contemporânea,
padronizações que viabilizem o reuso de blocos de
hardware são de grande importância, tendo em vista a
fabricação, caracterização, distribuição e aplicação de IP’s,
que são indispensáveis aos projetistas de circuitos
integrados e aos desenvolvedores de sistemas em chip.
Devido a este fato, o grupo de trabalho de Barramentos
em Chip (OCB - On-Chip Bus) da VSIA (Virtual Sockets
Interface Alliance) [1] desenvolveu o padrão VCI (Virtual
Component Interface), com o objetivo de gerar uma
interface padrão para o encapsulamento desses
componentes. O padrão VCI identifica os blocos reusáveis
como componentes virtuais ou VCs. Então, VCs de
diferentes origens podem ser conectados para a geração dos
sistemas em chip e podem ser utilizados em tantos
projetos quanto necessário, sem limitar seu uso a um
único projeto.
O padrão VCI disponibilizou uma família de interfaces
de componentes virtuais que são compatíveis entre si,
permitindo algumas escolhas aos projetistas de SoC’s
quanto à complexidade da interface de reuso a ser
empregada [1]. A principal característica do reuso de um
IP é a sua habilidade de ser facilmente integrado em um
SoC.
Este trabalho tem como objetivo apresentar o
desenvolvimento das interfaces BVCI Iniciadora e Alvo
em VHDL, bem como os resultados obtidos a partir de
sua síntese para FPGAs da Altera. Além disso, são
apresentados os experimentos desenvolvidos para a
verificação do correto funcionamento do protocolo de
handshake da interface BVCI, quando esta é utilizada em
um sistema complexo.
Na seção dois deste artigo faz-se uma breve descrição
sobre a interface BVCI de reuso de hardware, identificando
sua origem e suas características principais. Na seção três
o processo de desenvolvimento das interfaces BVCI
Iniciadora e Alvo é descrito. A seção quatro, por sua vez,
apresenta os resultados obtidos a partir da síntese das
interfaces BVCI Iniciadora e Alvo, comparados aos
resultados de outras interfaces e de blocos de hardware
desenvolvidos em trabalhos anteriores. Já na seção cinco
são apresentados os métodos utilizados para realizar a
validação do protocolo de comunicação das interfaces
BVCI. Finalmente, a seção seis apresenta as conclusões e
propostas para trabalhos futuros.
2. A INTERFACE BVCI
Definido pelo grupo de trabalho em Barramentos em
Chip (OCB) da VSIA [1], o padrão VCI (Virtual
Component Interface) [2] foi criado com o objetivo de
gerar uma interface padrão que permita que componentes
virtuais compatíveis se comuniquem para gerarem
sistemas em chip, mesmo que estes componentes sejam
desenvolvidos por diferentes projetistas, de diferentes
empresas. Assim, os componentes virtuais não terão seu
uso limitado a um único projeto, podendo ser
instanciados e utilizados em tantos projetos quanto forem
necessários.
O padrão VCI especifica uma família de protocolos de
comunicação que visam facilitar a comunicação entre os
VC’s. Atualmente, três protocolos pertencem a esta
família: o Peripheral Virtual Component Interface
(PVCI), o Basic Virtual Component Interface (BVCI) e o
Advanced Virtual Component Interface (AVCI) [2].
O protocolo PVCI provê uma interface simples e de
fácil implementação e é direcionado para aplicações que
não necessitam de todas as funcionalidades do BVCI. O
protocolo BVCI define uma interface apropriada para a
maioria das aplicações, possuindo um protocolo poderoso
e não muito complexo. O protocolo AVCI adiciona
recursos mais sofisticados em relação ao protocolo BVCI,
para suportar aplicações de alto desempenho [2].
Os objetivos iniciais considerados na elaboração do
padrão VCI foram [1]:
• A necessidade de máxima portabilidade para um VC,
onde um componente virtual deve poder ser usado
com barramentos com vários protocolos e de vários
níveis de desempenho.
• A simplicidade e a eficiência na implementação, com
um protocolo claro e de fácil compreensão, para que o
padrão seja amplamente aceito.
• A disponibilidade de uma família de interfaces de
componentes virtuais, com interfaces compatíveis,
permitindo algumas escolhas ao projetista do sistema
em chip e gerando mais oportunidades para o
projetista de componentes virtuais.
• A definição completa do protocolo, incluindo a
completa enumeração das possíveis interações, com
declarações sobre os comportamentos permitidos e não
permitidos, além de prover mecanismos para a
extensão deste protocolo.
A interface VCI pode ser usada para conexões ponto a
ponto entre duas unidades chamadas de iniciador e alvo,
onde o iniciador emite uma requisição e o alvo responde
[3].
O padrão VCI pode ser usado como interface para um
wrapper ou empacotador, que conecta-se a um
barramento. Esta é a forma pelo qual o padrão VCI
permite que os componentes virtuais sejam conectados em
qualquer barramento. Uma vez que tenham sido
desenvolvidos os empacotadores VCI para um
determinado barramento, qualquer componente virtual que
siga o padrão VCI pode ser conectado a este barramento.
[4]
A comunicação entre o iniciador e o alvo na interface
BVCI, está apresentada na Fig. 1.
Na Fig.1, o iniciador é responsável pelos conteúdos de
requisição e o alvo é responsável pelos conteúdos de
resposta. Estes conteúdos são transferidos separadamente
sob o controle de um protocolo simples chamado
handshake, onde as mensagens de requisição e resposta
são completamente independentes umas das outras. O
protocolo de handshake visa sincronizar dois blocos
transferindo informação de controle em ambas as direções.
Figura 1 - Conexão entre iniciador e alvo usando uma
Interface BVCI
A Fig. 2 mostra o funcionamento do protocolo
handshake, onde as linhas verticais tracejadas representam
as bordas de subida do clock. Nomes genéricos, VAL e
ACK, são usados na Fig. 2 como sinais de controle, estes
nomes representam os sinais CMDVAL e CMDACK do
canal requisição, e os sinais RSPVAL e RSPACK do
canal de resposta.
2
Figura 2 - Handshake de Controle para Requisição e Resposta (ACK Assíncrono)
Os conteúdos de requisição fluem do Iniciador para o
Alvo, pela ativação dos sinais CMDVAL e CMDACK,
e os conteúdos de resposta fluem do Alvo para o
Iniciador, pela ativação dos sinais RSPVAL e
RSPACK. Quando o sinal CMDVAL é ativado
significa que o Iniciador está solicitando a transferência
de um dado de leitura ou escrita para o Alvo. A ativação
do sinal CMDACK pelo Alvo, em resposta à solicitação
do Iniciador, indica que a transferência pode ser
realizada. E, ativando o sinal RSPVAL, o Alvo indica
que deseja executar a transferência do dado de resposta
para o Iniciador. O Iniciador, por sua vez, ativa o sinal
RSPACK indicando ao Alvo que está apto a receber o
conteúdo de resposta. Após o recebimento do conteúdo
pelo Iniciador, a transferência é finalizada. O sinal
CMDACK pode ser gerado assincronamente como
mostrado na Fig. 2, ou sincronamente, onde após a
ativação do sinal CMDVAL, solicitando uma
transferência de dados, o sinal de confirmação
(CMDACK) é gerado na próxima borda do clock.
3. O DESENVOLVIMENTO DAS INTERFACES
BVCI INICIADORA E ALVO
As interfaces BVCI Iniciadora e Alvo foram
desenvolvidas a partir da implementação de duas
máquinas de estados finitos (FSM – Finite State
Machine) [5] para cada interface. Estas FSM são
responsáveis pelo controle de transferências de dados
entre um bloco de hardware conectado à interface BVCI
Iniciadora e outro conectado à interface BVCI Alvo.
As máquinas de estados que integram as interfaces
BVCI Iniciadora e Alvo são compostas por três estados
cada uma: um estado que reseta o sistema, um estado
indicador de sistema ocioso e um estado que verifica se
uma operação (escrita/leitura) continua em andamento ou
pode ser finalizada. Na BVCI Iniciadora a máquina que
controla o canal de requisição possui como principais
sinais o CMDVAL e o CMDACK. Os principais sinais
da máquina que controla o canal de resposta na BVCI
Iniciadora e Alvo são os sinais RSPVAL e o RSPACK.
Na BVCI Alvo, a máquina responsável pelo canal de
requisição possui como sinais principais o CMDVAL e
o EOP.
Na Tab.1, estão relacionados os principais sinais que
compõem as Interfaces BVCI Iniciadora e Alvo e suas
respectivas descrições (origem e função).
Tabela 1 - Principais sinais das Interfaces BVCI
Sinal
CMDVAL
(Command
Valid)
Origem
Função
Iniciador Indica que o iniciador deseja
executar uma transferência de
célula para o alvo.
CMDACK
Alvo
Indica ao iniciador que uma
determinada célula pode ser
transferida.
RSPVAL
Alvo
Indica que o alvo deseja executar
uma transferência de célula de
resposta para o iniciador.
(Command
Acknowledge)
(Response
Valid)
RSPACK
Iniciador Indica ao alvo que uma
determinada célula será
transferida.
EOP
Iniciador Indica que todas as células
associadas a determinado pacote
foram transferidas.
(Response
Acknowledge)
(End of
Packet)
A interfaces BVCI possuem ainda diversos outros
sinais necessários ao seu perfeito funcionamento, entre
eles estão: sinal de CLOCK (provê a temporização para
todas as transações realizadas na interface, todos os
sinais são ativados na borda de subida do CLOCK),
RESETN (usado para deixar todos os dispositivos em
um estado comum, é um sinal ativo baixo). O sinal
CMD define o tipo de operação (leitura/escrita) que será
iniciada pelo Iniciador para o Alvo. O sinal BE indica
quais bytes da célula que são transferidos ou requeridos
pelo iniciador estão habilitados. O sinal ADDRESS é o
3
endereço da requisição e é gerado pelo iniciador e
recebido pelo alvo.
Nas Figs. 3 e 4 estão apresentadas as máquinas de
estados que compõem a BVCI Iniciadora, onde a Fig. 3
mostra a máquina de estados responsável pelo canal de
requisição e a Fig. 4 apresenta a máquina responsável
pelo canal de resposta. Estas máquinas de estados são
compostas por três estados: estado que inicializa o
sistema, estado indicador de sistema ocioso e estado
ativo, que realiza uma operação (escrita/leitura).
Como na simulação das interfaces Iniciadora e Alvo,
ainda não haviam blocos de hardware integrados as
mesmas, os sinais CMDVAL_tmp, RSPVAL_tmp e
RSPACK_tmp foram utilizados como entradas para
gerar estímulos para as interfaces.
As interfaces BVCI Iniciadora e Alvo foram
completamente descritas em VHDL no ambiente Quartus
II da Altera [6].
Figura 5 - Máquina de Estados Finitos responsável pelo
Canal de Requisição da BVCI Alvo
Figura 3 - Máquina de Estados Finitos responsável pelo
Canal de Requisição da BVCI Iniciadora
Figura 6 - Máquina de Estados Finitos responsável pelo
Canal de Resposta da BVCI Alvo
Figura 4 - Máquina de Estados Finitos responsável pelo
Canal de Resposta da BVCI Iniciadora
As Figs. 5 e 6 apresentam as máquinas de estados
que compõem a BVCI Alvo, sendo que a Fig. 5 contém
a máquina de estados responsável pelo canal de
requisição e, a Fig. 6 apresenta a máquina de estados
responsável pelo canal de resposta. Cada máquina é
composta por três estados como as máquinas que
compõem a interface BVCI Iniciadora, são eles:
inicializa, ocioso e ativo.
A síntese das interfaces BVCI também foi realizada
com auxílio da ferramenta QuartusII [2], sendo
direcionada para um FPGA da família FLEX 10KE da
Altera [6], mais especificamente o dispositivo
EPF10K130EQC240-1 [7].
Os resultados extraídos da síntese da interface BVCI
Iniciadora indicaram que foram utilizadas 50 células
lógicas e 50 pinos do dispositivo. Com relação ao
desempenho, a descrição da interface BVCI atingiu um
4
período mínimo de 5,3ns, o que corresponde a uma
freqüência máxima de operação de 188,7MHz.
Já os resultados de síntese da interface BVCI Alvo
indicaram a utilização de 26 células lógicas e 56 pinos
para o mesmo dispositivo, atingindo uma freqüência
máxima de operação de 163,9MHz, correspondente a um
período mínimo de 6,1ns.
Uma
das
dificuldades
encontradas
no
desenvolvimento das interfaces BVCI foi que,
diferentemente da interface PVCI já implementada em
trabalhos anteriores [9], a interface BVCI possui dois
handshakes independentes. Uma outra dificuldade surgiu
com relação à simulação da interface, pois não havia um
bloco de hardware integrado à interface para gerar
estímulos para a mesma e, por isso, foi necessário criar
um arquivo com formas de onda, o qual precisava ser
editado sempre que novos testes eram realizados.
Posteriormente, foram desenvolvidos blocos de hardware
específicos para possibilitar a validação do protocolo
através de simulações mais completas.
As interfaces BVCI foram validadas a partir de
simulações, onde foram gerados estímulos baseados em
todos os possíveis comportamentos de um bloco de
hardware integrado a esta interface.
4. RESULTADOS DE SÍNTESE
A Tab. 2 contém os resultados de síntese das interfaces
BVCI Iniciadora e Alvo, comparados aos resultados das
interfaces PVCI Iniciadora e Alvo [10], OCP Mestre e
Escravo [11], desenvolvidas em trabalhos anteriores, e de
blocos de hardware de um compressor JPEG e de uma
DCT 2-D, também desenvolvidos em trabalhos
anteriores [12], que são candidatos a utilizar as interfaces
BVCI em trabalhos futuros. Esta comparação com estes
blocos de hardware permitiu a construção de uma idéia
mais precisa sobre os impactos que a aplicação das
interfaces BVCI irão causar nestes blocos e, com isso,
indicar se a utilização desta interface é realmente
vantajosa. A síntese de todos os blocos e interfaces foi
direcionada para o FPGA EPF10K130EQC240-1 da
Altera.
A partir da Tab. 2, é possível perceber que a
freqüência máxima de operação das interfaces BVCI
Iniciadora e Alvo atingiu 57% e 49%, respectivamente,
da máxima freqüência permitida para o dispositivo
utilizado, que é de 333,33MHz. Estes resultados foram
considerados positivos, uma vez que a ferramenta de
análise de timing do Quartus II apresenta resultados
sabidamente pessimistas em relação ao atraso máximo,
por realizar uma análise estática de timing [8].
É possível observar na Tab. 2 que as interfaces BVCI
Iniciadora e Alvo, como esperado, utilizam mais células
lógicas que as interfaces PVCI (cerca de 3 vezes) e OCP
(cerca de 2,5 vezes), uma vez que as interfaces PVCI
possuem um protocolo de menor complexidade com
relação as interfaces BVCI, e as interfaces OCP possuem
complexidades comparáveis aquelas das interfaces PVCI.
Por outro lado, é possível perceber que tanto as
interfaces BVCI quanto as interfaces PVCI e OCP
utilizam cerca de 70 vezes menos células lógicas que os
blocos de hardware utilizados na comparação (DCT 2-D
e compressor JPEG). Destes resultados é possível prever
que a inserção destas interfaces nestes e em outros blocos
de hardware gerará um impacto muito pequeno em
termos de consumo de recursos.
Tabela 2 – Resultados de Síntese
Bloco de
Hardware
Células Freqüência
Lógicas
(MHz)
Período
(ns)
BVCI Iniciadora
50
188,7
5,3
BVCI Alvo
26
163,9
6,1
PVCI Iniciadora
19
121,9
8,2
PVCI Alvo
8
333,3
3
OCP Mestre
28
333,3
3
OCP Escravo
20
263,16
3,8
DCT – 2D
3.516
30,1
33,2
Compressor JPEG
4.363
31,1
32,2
Do ponto de vista de freqüência de operação, a Tab.
2, apresenta resultados mais animadores ainda, pois as
interfaces BVCI tiveram desempenho similar aos das
interfaces PVCI e OCP, e as três possuem um
desempenho 5 vezes superior ao da DCT 2-D e do
compressor JPEG, indicando que a inclusão destas
interfaces em blocos de hardware como os apresentados
não gerará impacto em termos de desempenho.
5. VALIDAÇÃO DO PROTOCOLO
A validação do protocolo foi realizada conectando as
interfaces BVCI Iniciadora e Alvo e estabelecendo um
processo de comunicação entre elas através dos sinais de
handshake, verificando assim a correta execução do
protocolo. Conforme representado na Fig. 7, tanto a
interface BVCI Iniciadora quanto a Alvo foram
integradas a blocos de estímulos, os quais simularam
blocos de hardware quaisquer, executando pedidos de
transferências de dados ou permanecendo em estado
ocioso.
A validação das interfaces BVCI também foi realizada
com auxílio da ferramenta QuartusII [2] e foi direcionada
para o mesmo dispositivo das sínteses anteriores, ou
seja, o EPF10K130EQC240-1 [7] da Altera [6].
Os resultados de síntese extraídos da integração entre
as interfaces indicaram que foram utilizadas 187 células
lógicas
e
125
pinos
do
dispositivo
EPF10K130EQC240-1, apresentando um período
mínimo de 9,5ns e uma freqüência máxima de operação
de 105,3MHz.
5
O protocolo foi validado a partir de várias
simulações, onde os blocos de estímulos ligados a cada
uma das interfaces simularam todos os possíveis
comportamentos de quaisquer blocos de hardware que
estivessem integrados as mesmas. Tais simulações foram
realizadas para avaliar a validade e correção da
implementação do protocolo BVCI e obtiveram
resultados positivos, os quais indicaram que a
implementação está funcional e correta. Porém,
simulações adicionais serão realizadas para verificar o
comportamento do protocolo sob comunicações de longa
duração, onde o tipo de comunicação e a quantidade de
dados transferidos irão variar aleatoriamente, com o
objetivo de captar alguma possível incorreção na
implementação que não tenha sido detectada nas
primeiras simulações.
Um exemplo de forma de onda obtida com a
simulação está apresentada na Fig. 8 onde, em um
primeiro momento, indicado pela letra “a”, a
comunicação entre as interfaces é inicializada pela
ativação do sinal RESETN (ativo baixo). Na primeira
borda ascendente de clock depois que o sinal RESETN
é desativado, indicada pela letra “b” na Fig. 8, a interface
passa para o estado ocioso, ou seja, nenhuma transação
está sendo solicitada pelo bloco de hardware conectado à
BVCI Iniciadora. Na próxima borda ascendente de clock
após o sinal CMDVAL ser ativado pela interface
iniciadora, indicada pela letra “c” na Fig. 8, então está
sendo solicitada a transferência de um dado que, nesse
caso, é um dado de leitura pois o sinal CMD está setado
como o valor um. Neste instante, o endereço de leitura
também é disponibilizado no barramento ADDRESS,
indicando a localização do dado que será lido. No
instante indicado pela letra “d” na Fig. 8, ainda no
handshake de requisição, o sinal CMDACK é ativado
pelo alvo para indicar que a transferência pode ser
realizada. Na simulação apresentada na Fig. 8 (letra “d”),
o alvo responde imediatamente à requisição do iniciador,
através do handshake de resposta, ativando o sinal
RSPVAL para indicar que o alvo deseja executar a
Bloco de
Hardware
BVCI
Iniciadora
Sinais de
Controle
transferência do dado de resposta para o iniciador e,
como a operação solicitada é de leitura, o alvo
disponibiliza também o dado de leitura no barramento
RDATA. A interface iniciadora, por sua vez, ativa o
sinal RSPACK no instante indicado pela letra “e” na
Fig. 8, indicando ao alvo que está apta para receber o
conteúdo de resposta. Após a interface iniciadora receber
o conteúdo, a operação é finalizada.
Ainda no instante indicado pela letra “e” na Fig. 8 a
interface iniciadora volta para o estado ocioso. No
instante indicado pela letra “f” a interface iniciadora faz
uma requisição de escrita, setando o valor dois para o
sinal CMD. A operação de escrita é semelhante à
operação de leitura descrita anteriormente, porém, ao
ativar o sinal CMDVAL, a interface iniciadora
disponibiliza o endereço de escrita no barramento
ADDRESS e o dado a ser escrito no barramento
WDATA. O alvo, durante o handshake de resposta,
ativa somente o sinal RSPVAL para indicar ao iniciador
que aceita executar a operação de escrita.
A forma de onda da Fig. 8 foi obtida a partir de uma
simulação que monitorava todos os sinais relacionados a
comunicação entre dois blocos de hardware e, neste caso,
entre os blocos de estímulos ligados a cada interface.
Foram considerados, nesta simulação, três monitores:
• Monitor 1: responsável pela transferência dos
sinais entre o bloco de estímulos da Interface
Iniciadora e a Interface Iniciadora;
• Monitor 2: responsável pela transferência dos
sinais entre as Interfaces Iniciadora e Alvo;
• Monitor 3: responsável pela transferência dos
sinais entre a Interface Alvo e o bloco de estímulos
da desta interface.
Como está simulação gerou uma grande quantidade
de formas de onda, devido ao grande número de sinais
do protocolo de handshake a serem transferidos, optouse por extrair da mesma a forma de onda da Fig. 8, a
qual contém os sinais do Monitor 2, pois esta figura já
apresenta os resultados que se deseja demonstrar.
BVCI
Alvo
Bloco de
Hardware
Dados
Figura 7 - Interfaces BVCI Iniciadora e Alvo integradas a blocos de hardware, visando o reuso desses módulos
6
Figura 8 - Exemplo de resultado de uma simulação das interfaces BVCI estabelecendo a comunicação entre dois blocos de
hardware genéricos.
6. CONCLUSÕES E TRABALHOS FUTUROS
Este artigo apresentou o desenvolvimento das
interfaces para reuso de hardware do padrão BVCI. As
interfaces foram descritas em VHDL e sintetizadas para
FPGA’s da Altera. As interfaces e seu protocolo de
handshake foram validados através de experimentos onde
estas interfaces foram agregadas a blocos de hardware
geradores e recebedores de estímulos. Através de várias
simulações, foi possível verificar o
correto
funcionamento do protocolo de comunicação em todas as
formas de comunicação permitidas pelo protocolo.
Os resultados de síntese indicaram que a interface
BVCI iniciadora utilizou 50 células lógicas do FPGA
selecionado, estando apta a operar em uma freqüência de
operação máxima de 189MHz. Por outro lado, a interface
BVCI alvo utilizou 26 células lógicas e está apta a
operar a 164MHz.
Estes resultados foram utilizados para comparar as
interfaces BVCI com as interfaces PVCI e OCP,
desenvolvidas em trabalhos paralelos. Desta comparação,
foi possível perceber, como era esperado, que as
interfaces BVCI, por possuírem um protocolo mais
completo, utilizaram mais células lógicas, mas atingiram
uma freqüência de operação similar à das interfaces PVCI
e OCP.
Os resultados de síntese também permitiram a
realização de uma comparação entre as interfaces BVCI e
alguns blocos de hardware, mais especificamente, um
compressor JPEG e uma DCT 2-D, que foram
desenvolvidos em trabalhos anteriores e que são
candidatos a receber as interfaces BVCI em trabalhos
futuros. Esta comparação indicou que as interfaces BVCI
utilizam cerca de 70 vezes menos células lógicas do
FPGA alvo do que o compressor JPEG ou a DCT 2-D.
Além disso, a freqüência de operação das interfaces
BVCI foi cerca de 5 vezes maior do que para o
compressor e a DCT 2-D. Deste modo, foi possível
estimar que os impactos da inserção das interfaces BVCI
nos blocos de hardware causará um impacto mínimo em
termos de uso de recursos e não causará impacto nenhum
em termos de desempenho, tendo em vista que as
interfaces possuem freqüências de operação próximas à
máxima freqüência de operação do dispositivo.
Os resultados deste trabalho foram considerados
animadores e, por isso, como trabalhos futuros, está
planejada a inserção das interfaces BVCI na DCT 2-D e
no compressor JPEG, para verificar a funcionalidade das
interfaces em sistemas complexos e para avaliar os
impactos reais causados em termos de uso de recursos e
de desempenho. Obtidos os resultados finais destes
experimentos, estes resultados serão comparados aos
resultados obtidos em experimentos dessa mesma
natureza só que realizados utilizando as interfaces padrão
PVCI [2] e OCP [13] de reuso de hardware.
7. REFERÊNCIAS
[1] VSI Alliance, <www.vsia.org>, Julho 2004.
[2] VSIA. On-Chip Bus Development Working Group.
Virtual Component Interface Standard (OCB 2.1.0). Março
2000.
[3] G. Cyr, G. Bois, M. Aboulhamid, “Synthesis of
communication
interface
for
SoC
using
VSIA
recommendations”, Proc. of DATE 2001, Munich,
Allemagne/Germany, Março 2001.
[4] R. Lysecky, F. Vahid, T. Givargis, “Experiments with
the Peripheral Virtual Component Interface”, International
Symposium on System Synthesis, Madri, Espanha,
Setembro 2000.
7
[5] S. Brown, Z. Vranesic, Fundamentals of Digital Logic
with VHDL Design, The MacGraw-Hill Companies, USA,
2000.
[6] Altera Corporation, “Altera: The Programmable
Solutions Company”, <http://www.altera.com>, 2003.
[7] “FLEX 10KE – Embedded Programmable Logic Devices
Data Sheet – version 2.3”. San Jose, Altera Corporation,
2001.
[8] F. Nekoogar, Timing Verification of ApplicationSpecific Integrated Circuits (ASICs), Prentice Hall PTR,
New Jersey, USA, 1999.
[9] T. Silva, R. Porto, R. Tavares, L. Agostini, “Experimentos
com a Interface de Reuso PVCI em uma DCT 2-D
Direcionada para a Compressão JPEG”, X Workshop
Iberchip, Cartagena de Índias, Colômbia, Março 2003.
[10] R. Tavares, L. Agostini. “Avaliação dos Impactos d o
Reuso de Hardware Através da Implementação de uma
Interface PVCI Integrada a uma Arquitetura de Cálculo da
DCT 2-D”, XI Congresso de Iniciação Científica da
Universidade Federal de Pelotas, Pelotas, Brasil, 2003.
[11] M. Porto, L. Agostini, “Experimentos com o Padrão de
Reuso de Hardware OCP (Open Core Protocol)”, X
Workshop Iberchip, Cartagena de Índias, Colômbia, Março
2003.
[12] 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, 2002.
[13] OCP–International Partnership. Open Core Protocol
Specification (Release 1.0).2001.
8