Carlos Rodrigo Tofoli Fernandes
CriptoCore: Projeto, valida¸
c˜
ao e
prototipa¸
c˜
ao de um IP
Florian´opolis – SC Novembro / 2005
Carlos Rodrigo Tofoli Fernandes
CriptoCore: Projeto, valida¸
c˜
ao e
prototipa¸
c˜
ao de um IP
Orientador:
Prof. Dr. Luiz Cl´
audio dos Santos
Bacharelado em Ciˆencias da Computac¸˜ao Departamento de Inform´atica e Estat´ıstica
Centro Tecnol´ogico
Universidade Federal de Santa Catarina
Florian´opolis – SC Novembro / 2005
“I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.” Bjarne Stroustrup
Resumo
O crescimento dos SoCs foi o resultado de dois fatores: a crescente oferta de hardware amparada pela lei de Moore e a demanda de aplica¸c˜oes industriais cada vez mais comple-xas, especialmente nos dom´ınios de eletrodom´esticos e telecomunica¸c˜oes. Projeto baseado em plataforma ´e uma resposta metodol´ogica para os altos custos no desenvolvimento de sistemas digitais com as tecnologias contemporˆaneas. Referˆencia arquitetural, reuso de IP e ESL s˜ao mecanismos chave para tratar com a complexidade e time-to-market. A necessidade de ganhos de produtividade pede por modelos de IP em diferentes n´ıveis de abstra¸c˜ao. Este trabalho descreve o projeto, a valida¸c˜ao e a prototipa¸c˜ao de um IP em trˆes n´ıveis de abstra¸c˜ao distintos.. O IP, chamado Criptocore, implementa a exponencia¸c˜ao modular, uma opera¸c˜ao crucial usada em importantes aplica¸c˜oes criptogr´aficas. Resulta-dos experimentais evidenciam a valida¸c˜ao apropriada e permitem uma an´alise quantitativa do ganho de produtividade.
Abstract
The rise of SoCs was the result of two interacting factors: the increasing supply of hardware ruled by Moore?s Law and the demand of complex industrial applications, especially in the domains of consumer electronics and telecommunications. Platform-based design is the methodological response to the high costs of non-recurring engineering associated with contemporary technologies. Architectural reference, IP reuse and ESL are key mechanisms to cope with complexity and time-to-market. The need for productivity gains asks for IP models in different levels of abstraction. This paper describes the design, validation and prototyping of an IP in three distinct abstraction levels. The IP, called CriptoCore, implements modular exponentiation, a crucial operation used in important cryptographic applications. Experimental results give evidence of proper validation and allow the quantitative assessment of productivity gain.
Sum´
ario
Lista de Figuras
1 Introdu¸c˜ao p. 8
2 Trabalhos correlatos p. 10
3 Descri¸c˜ao do Criptocore p. 11
3.1 Descri¸c˜ao execut´avel . . . p. 12 3.2 Descri¸c˜ao funcional . . . p. 13 3.3 Descri¸c˜ao RT . . . p. 13 3.3.1 Tradu¸c˜ao para VHDL . . . p. 13 3.3.1.1 Driver de acesso ao IP . . . p. 14 3.4 Valida¸c˜ao . . . p. 15 4 Prototipa¸c˜ao p. 17 4.1 A plataforma de prototipa¸c˜ao . . . p. 17 4.2 Driver de acesso ao IP . . . p. 17 4.3 Restri¸c˜oes impostas pela plataforma-alvo . . . p. 17
5 Resultados experimentais p. 19
5.1 Experimentos atrav´es de simula¸c˜ao . . . p. 19 5.1.1 Configura¸c˜ao . . . p. 19 5.1.2 Procedimento . . . p. 19 5.1.3 Resultados . . . p. 19
5.2 Experimentos com o prot´otipo . . . p. 21 5.2.1 Configura¸c˜ao . . . p. 21 5.2.2 Procedimento . . . p. 21 5.2.3 Resultados . . . p. 21
6 Conclus˜oes e perspectivas p. 22
Referˆencias p. 23
Anexo p. 24
Anexo A - C´odigo fonte. . . p. 24 Anexo B - Artigo . . . p. 36
Lista de Figuras
1 Algoritmo Standard Interleaved . . . p. 12 2 Algoritmo RL Binary Method . . . p. 12 3 Arquitetura da multiplica¸c˜ao modular . . . p. 14 4 Arquitetura da exponencia¸c˜ao modular . . . p. 15 5 Estrutura dos m´odulos . . . p. 15 6 Complexidade das descri¸c˜oes . . . p. 20 7 Tempos de simula¸c˜ao/execu¸c˜ao . . . p. 20
8
1
Introdu¸
c˜
ao
Cada vez mais ´e poss´ıvel colocar um n´umero maior de componentes dentro de uma mesma pastilha de sil´ıcio. Com isso a complexidade dos sistemas criados tamb´em aumen-tam. Juntando isto a press˜ao de se colocar o produto no mercado em um tempo cada vez menor, construir um sistema por completo se torna invi´avel. ´E neste contexto que surge as atuais linguagem de descri¸c˜ao de sistemas, onde o reuso de componentes ´e mandat´orio. O reuso de componentes ´e feito atrav´es dos cores IP (m´odulos de propriedade inte-lectual), que nada mais s˜ao do que m´odulos que implementam uma certa funcionalidade. Assim para se construir um sistema basta juntar os cores IP que implementam as funci-onalidades desejadas.
Para auxiliar na constru¸c˜ao desses sistemas surgiram linguagens capazes de descrever sistemas digitais. As primeiras com um n´ıvel de detalhe que possibilita a s´ıntese das descri¸c˜oes em hardware, mas a medida que os sistemas foram aumentado sua complexidade novas linguagens foram surgindo para suprir a necessidade de descri¸c˜ao dos sistemas em um n´ıvel mais alto.
Com os v´arios n´ıveis de descri¸c˜ao poss´ıveis surgiram metodologias de constru¸c˜ao de sistemas cujo objetivo ´e definir quais n´ıveis devem ser descritos primeiro e como tran-sicionar entre as descri¸c˜oes para que seja poss´ıvel construir o sistema de maneira mais eficiente.
Neste contexto este trabalho tem como objetivo construir um IP e sintetiz´a-lo em l´ogica program´avel (FPGA). Para isso usar´a uma metodologia top-down[1], que consiste em descrever a funcionalidade do IP em um n´ıvel de abstra¸c˜ao alto e atrav´es de refina-mentos sucessivos descrever o IP em n´ıveis de abstra¸c˜ao cada vez mais baixos at´e que se obtenha uma descri¸c˜ao sintetiz´avel. Neste trabalho os seguintes n´ıveis de descri¸c˜ao ser˜ao usados:
1 Introdu¸c˜ao 9
• Descri¸c˜ao funcional • Descri¸c˜ao RT
Para valida¸c˜ao do IP, ser´a aplicado um mesmo conjunto de est´ımulos a todas as descri¸c˜oes e o resultado obtido ser´a comparado a descri¸c˜ao de n´ıvel superior. Esses mesmos est´ımulos usados na valida¸c˜ao das descri¸c˜oes ser´a aplicado no prot´otipo para valid´a-lo.
10
2
Trabalhos correlatos
V´arios IPs para aplica¸c˜oes criptogr´aficas s˜ao reportados na literatura [2–4]. A maior parte dos IPs implementa algoritmos criptogr´aficos sim´etricos, tais como o DES [3] e o AES [4]. H´a IPs que implementam opera¸c˜oes freq¨uentemente utilizadas em algoritmos criptogr´aficos, como a exponencia¸c˜ao modular [2, 5].
Para realizar a exponencia¸c˜ao modular, todos os IPs encontrados pelos autores utili-zam o algoritmo Left-to-Right binary [2]. Por sua vez, para realizar a multiplica¸c˜ao mo-dular (opera¸c˜ao primitiva utilizada pela exponencia¸c˜ao), a literatura reporta uma gama bastante extensa de algoritmos. Dentre os mais usados est˜ao Interleaved Standard Multi-plication [2], o Optimized Interleaved Standard MultiMulti-plication [5] e varia¸c˜oes do algoritmo de Montgomery [6].
No entanto, em sua grande maioria, os IPs s˜ao descritos apenas no n´ıvel RT e poucos s˜ao disponibilizados ao dom´ınio p´ublico.
A carˆencia de IPs de dom´ınio p´ublico descritos em v´arios n´ıveis de abstra¸c˜ao motivou a proposta de reposit´orios orientados ao desenvolvimento de plataformas, tais como os dos projetos BrazilIP[7] e ArchC[8] (especialmente em sua vers˜ao 2.0).
11
3
Descri¸
c˜
ao do Criptocore
O Criptocore realiza a opera¸c˜ao de exponencia¸c˜ao modular (C = Xe mod M ), freq¨uentemente utilizada em aplica¸c˜oes criptogr´aficas, tais como encripta¸c˜ao RSA, al-goritmo de Diffie-Hellman e assinatura digital.
O IP Ter´a 3 entradas (Base, Expoente e M odulo) e uma sa´ıda (Resultado), todas com 32 bits. A representa¸c˜ao interna dos n´umeros tamb´em ser´a de 32 bits.
Para realizar a exponencia¸c˜ao modular, escolheu-se o algoritmo Left-to-Right binary[9], por ser o mais adequado `a manipula¸c˜ao de n´umeros inteiros representados com um grande n´umero de bits.
A Figura 1 descreve o algoritmo escolhido, onde P representa uma estimativa parcial da exponencia¸c˜ao modular a ser refinada iterativamente. Dada a representa¸c˜ao bin´aria do expoente e, seus bits s˜ao visitados do mais significativo (MSB) para o menos signi-ficativo (LSB), de forma que a estimativa corrente ´e elevada ao quadrado para cada bit visitado. A multiplica¸c˜ao modular ´e invocada somente se o bit visitado for “1”. Para re-alizar a multiplica¸c˜ao modular no passo 2a da Figura 1 escolheu-se o algoritmo Standard Interleaved [6], por raz˜oes de praticidade.
A Figura 2 descreve o algoritmo escolhido, onde P representa uma estimativa parcial do produto modular. Dada a representa¸c˜ao bin´aria da base X, seus bits s˜ao visitados do MSB para o LSB, de forma que uma nova estimativa P ´e obtida a cada bit Xi visitado. Para obter uma estimativa parcial, a id´eia ´e intercalar multiplica¸c˜ao e m´odulo de maneira que os resultados intermedi´arios sejam mantidos t˜ao pequenos quanto poss´ıvel. O passo 3 garante o correto alinhamento dos produtos parciais: o produto acumulado na itera¸c˜ao anterior ´e o dobro do produto parcial calculado na itera¸c˜ao atual, pois os bits s˜ao visitados do MSB para o LSB. O passo 4 realiza um produto parcial e o acumula. Os passos 5 e 6 aplicam a opera¸c˜ao de m´odulo ao produto acumulado, dele subtraindo o valor M at´e se obter P < M .
con-3.1 Descri¸c˜ao execut´avel 12 Entrada: X, M, Y com 0 =< X, Y, M Sa´ıda: P = X ∗ Y M od M Xi : iesimobitdeX (1) P := 0 (2) F or n − 1 downto 0 do { (3) P := 2 ∗ P (4) I := Xi∗ Y (5) P := P + I (6) W hile (P >= M ) (7) P := P − M } (8)
Figura 1: Algoritmo Standard Interleaved Entrada: X, e, M
Saida: M = Xe M od M en: en´esimo bit de e (1) P := 1
(2) F or n − 1 downto 0 do { (2a) P := P ∗ P
(2b) if en= 1 then P := P ∗ X mod M }
Figura 2: Algoritmo RL Binary Method
siste em descrever a funcionalidade do IP em um alto n´ıvel de abstra¸c˜ao e, atrav´es de refinamentos sucessivos, descrever o IP em n´ıveis de abstra¸c˜ao cada vez mais baixos at´e que se obtenha uma descri¸c˜ao sintetiz´avel. Neste trabalho, s˜ao usados os seguintes n´ıveis de descri¸c˜ao: algor´ıtmico, funcional com precis˜ao de bits e RT.
3.1
Descri¸
c˜
ao execut´
avel
Neste n´ıvel o IP tem seu algoritmo implementado em alto n´ıvel. A comunica¸c˜ao entre os m´odulos e a representa¸c˜ao interna dos n´umeros ainda tem n´umero de bits arbitr´arios. As entradas e sa´ıdas deste n´ıvel s˜ao gerenciadas pelo SystemC[10] atrav´es de canais do tipo FIFO. Sempre que ´e detectado a chegada de dados nas entradas, uma thread ´e disparada e executa o algoritmo da exponencia¸c˜ao modular. Ap´os isso o resultado ´e disponibilizado na sa´ıda.
3.2 Descri¸c˜ao funcional 13
3.2
Descri¸
c˜
ao funcional
Neste n´ıvel o m´odulo que representa o hardware j´a passa a ser bit accurate, ou seja, a representa¸c˜ao dos dados ser´a feita com o n´umero de bits que ser˜ao usados no sistema real. N˜ao existe nenhuma mudan¸ca na estrutura, apenas o algoritmo precisou ser adaptado a nova representa¸c˜ao num´erica.
3.3
Descri¸
c˜
ao RT
No n´ıvel RT, a estrutura do IP ´e descrita em termos de seus componentes b´asicos (tais como somador, registradores, deslocadores, etc.), os quais realizam o comportamento do algoritmo, dirigidos por uma unidade de controle. Esbo¸cos dos principais blocos do IP s˜ao apresentados nas Figuras 3 e 4.
A Figura 3 mostra os principais componentes do multiplicador modular. Vale ressaltar que o shifter implementa o passo 3 do algoritmo da Figura 1, enquanto o somador ´e usado para implementar os passos 5 e 7. O registrador armazena as estimativas parciais P da multiplica¸c˜ao modular.
Por sua vez, a Figura 4 ilustra os principais componentes do exponenciador modular. O bloco ModMul encapsula o circuito da Figura 3, enquanto o registrador armazena as estimativas parciais P da exponencia¸c˜ao modular.
Ao contr´ario das descri¸c˜oes anteriores, a comunica¸c˜ao entre os m´odulos ´e modelada atrav´es de sinais em SystemC. Por isso, novos canais foram criados para que a unidade de controle conseguisse gerenciar a comunica¸c˜ao entre m´odulos.
Nesta fase de projeto, percebeu-se a necessidade de criar duas entradas e uma nova sa´ıda na interface: uma entrada para comandar o in´ıcio de uma opera¸c˜ao no IP, uma entrada para o clock e uma sa´ıda para sinalizar a disponibilidade do resultado.
3.3.1
Tradu¸
c˜
ao para VHDL
Por n˜ao dispor de uma ferramenta que sintetize SystemC[10] RTL, uma tradu¸c˜ao para VHDL teve que ser feita. Conceitualmente n˜ao existem diferen¸cas entre as duas descri¸c˜oes, portanto todos os canais e m´odulos s˜ao mantidos inalterados. Apenas mudan¸cas relativas a linguagem foi necess´aria neste est´agio.
3.3 Descri¸c˜ao RT 14
Figura 3: Arquitetura da multiplica¸c˜ao modular
I[11]), e o acesso ao Criptocore ´e feito atrav´es da CPU. Para isso teve que ser criado um wrapper para o IP de maneira que ele pudesse entender o protocolo AVALON[12] (protocolo de comunica¸c˜ao usado pelo barramento do NIOS I).
3.3.1.1 Driver de acesso ao IP
Um driver de acesso ao IP foi constru´ıdo para facilitar o acesso atrav´es da CPU. Como o IP est´a conectado ao barramento do NIOS, o driver simplesmente cria ponteiros para o endere¸co no barramento em que o Criptocore foi conectado. Abaixo podemos ver os m´etodos dispon´ıveis para fazer o acesso ao IP:
• init(int x, int y, int m) Inicia o IP com os valores passados como parˆametro. • isReady() Retorna 1 quando o resultado j´a est´a dispon´ıvel na sa´ıda.
3.4 Valida¸c˜ao 15
Figura 4: Arquitetura da exponencia¸c˜ao modular
Ap´os iniciar o Criptocore ´e preciso uma espera ocupada, verificando se o valor do resultado j´a est´a dispon´ıvel, para ent˜ao peg´a-lo.
3.4
Valida¸
c˜
ao
Dois m´odulos adicionais foram criados para fazer a valida¸c˜ao do IP. O m´odulo STIM-GEN que lˆe valores em um arquivo e os repassa ao Criptocore e o m´odulo MONITOR que salva os resultados gerados pelo IP num arquivo. A estrutura de valida¸c˜ao pode ser vista da figura 5.
Figura 5: Estrutura dos m´odulos
A descri¸c˜ao execut´avel ´e a implementa¸c˜ao em alto n´ıvel do algoritmo que implementa a funcionalidade do IP. Partimos com a hip´otese da corretude desde n´ıvel para poder
3.4 Valida¸c˜ao 16
validar os demais. Um vetor de est´ımulos ´e aplicado ao modelo e seus resultados serviram de referˆencia para a descri¸c˜ao de n´ıvel inferior.
A partir da descri¸c˜ao funcional, cada descri¸c˜ao ´e submetida a um mesmo vetor de est´ımulos e seus resultados comparados com a descri¸c˜ao de n´ıvel superior. Uma vez que o vetor de resultados ´e igual ao n´ıvel superior a descri¸c˜ao ´e considerada v´alida. Os resultados produzidos pelo IP Criptocore conferem em todos os n´ıveis de descri¸c˜ao, sendo assim validado.
17
4
Prototipa¸
c˜
ao
4.1
A plataforma de prototipa¸
c˜
ao
A plataforma de que se dispunha para prototipa¸c˜ao (veja Se¸c˜ao 5.2.1) permite o uso de um softcore, a CPU NIOS I, e a conex˜ao de IPs ´e feita atrav´es do barramento AVALON. Para permitir a intera¸c˜ao com a CPU, um wrapper foi criado para o Criptocore, compatibilizando-o com o protocolo daquele barramento.
4.2
Driver de acesso ao IP
Um driver de acesso ao Criptocore foi constru´ıdo para viabilizar sua intera¸c˜ao com a CPU. Como o IP est´a diretamente conectado ao barramento, o driver consiste essenci-almente na cria¸c˜ao de ponteiros que representam o endere¸co associado ao Criptocore no barramento. O driver possui trˆes m´etodos de acesso ao IP:
• init(int x, int y, int m): Inicia o IP com os valores passados como parˆametro. • isReady(): Retorna 1 quando o resultado j´a est´a dispon´ıvel na sa´ıda.
• getOutput(): Retorna o resultado da opera¸c˜ao.
Ap´os a inicializa¸c˜ao do Criptocore, s˜ao necess´arios alguns ciclos de busy waiting, enquanto aguarda-se a disponibilidade do resultado, para ent˜ao captur´a-lo.
4.3
Restri¸
c˜
oes impostas pela plataforma-alvo
As descri¸c˜oes do Criptocore nos trˆes n´ıveis de abstra¸c˜ao adotados permitem a repre-senta¸c˜ao de valores com um n´umero gen´erico n de bits. Preferencialmente, o n´umero de bits deveria ser grande (e.g. n = 1024 bits) para uso em aplica¸c˜oes reais. Entretanto,
4.3 Restri¸c˜oes impostas pela plataforma-alvo 18
considerando a exig¨uidade de elementos l´ogicos na placa disponibilizada como plataforma-alvo, a representa¸c˜ao adotada nas descri¸c˜oes restringe-se a n=32 bits, inclusive as entradas e sa´ıdas do IP. Note que esta ´e uma restri¸c˜ao imposta exclusivamente para fins de proto-tipagem, sem perda da generalidade das descri¸c˜oes do Criptocore.
19
5
Resultados experimentais
5.1
Experimentos atrav´
es de simula¸
c˜
ao
5.1.1
Configura¸
c˜
ao
Todos os experimentos foram executados em um notebook Toshiba com processador Intel 1.7GHz, sob o sistema operacional Gentoo Linux (kernel-2.6.12). Para modelagem e compila¸c˜ao utilizaram-se SystemC-2.0.1[10] e GCC-3.3.5[13]. As simula¸c˜oes VHDL foram feitas na ferramenta Quartus-4.2[14].
5.1.2
Procedimento
Foi gerado um arquivo com 3 milh˜oes de n´umeros aleat´orios de 32 bits. Estes n´umeros servem de entrada para o m´odulo de est´ımulo, que ir´a atribuir o primeiro n´umero do arquivo a X, o segundo a Y e o terceiro a M at´e que se esgotem os n´umeros do arquivo. Com isso o m´odulo que implementa o IP ser´a estimulado 1 milh˜ao de vezes. O IP ent˜ao envia o resultado a um terceiro m´odulo que salva o resultado em um arquivo diferente do que cont´em os est´ımulos.
Uma vez com o arquivo de resultados, ele ´e confrontado contra o arquivo de resultados da descri¸c˜ao de n´ıvel superior at´e que n˜ao ajam diferen¸cas.
5.1.3
Resultados
Os resultados experimentais s˜ao ilustrados nas Figuras 6 e 7. A Figura 6 ilustra a complexidade das descri¸c˜oes em SystemC[10], expressa em n´umero de linhas, enquanto a Figura 7 mostra os tempos de simula¸c˜ao das descri¸c˜oes em SystemC[10] e o tempo de execu¸c˜ao no prot´otipo. Como esperado, os tempos de simula¸c˜ao aumentam `a medida que o n´ıvel de abstra¸c˜ao das descri¸c˜oes diminui. Note que a simula¸c˜ao funcional ´e cerca de 56 vezes mais lenta que a algor´ıtmica, embora n˜ao haja diferen¸ca sens´ıvel em sua
5.1 Experimentos atrav´es de simula¸c˜ao 20
Figura 6: Complexidade das descri¸c˜oes
complexidade. Isto se deve `a utiliza¸c˜ao do tipo textitfixed point de SystemC[10] para modelar os efeitos de precis˜ao finita. Note que a simula¸c˜ao no n´ıvel RT ´e cerca de 5 vezes mais lenta do que a simula¸c˜ao no n´ıvel funcional, dando uma evidˆencia quantitativa do ganho de produtividade potencial ao se trabalhar em n´ıveis mais altos de abstra¸c˜ao.
5.2 Experimentos com o prot´otipo 21
5.2
Experimentos com o prot´
otipo
5.2.1
Configura¸
c˜
ao
O Criptocore foi implementado em uma plataforma de prototipa¸c˜ao da Altera, modelo APEX20K[15]. A freq¨uˆencia de rel´ogio utilizada foi de 33MHz. Os dados de est´ımulo foram enviados `a CPU NIOS[11] atrav´es da porta serial da plataforma de prototipa¸c˜ao.
5.2.2
Procedimento
Devido a uma dificuldade t´ecnica de controlabilidade, n˜ao foi poss´ıvel capturar o tempo do prot´otipo com exatamente os mesmo est´ımulos utilizados nas simula¸c˜oes. O tempo que aparece na Figura 7 ´e o tempo que o prot´otipo demorou para executar o mesmo n´umero de opera¸c˜oes do arquivo de est´ımulos usado nas simula¸c˜oes das descri¸c˜oes.
5.2.3
Resultados
Conforme ilustra a Figura 7, o tempo de execu¸c˜ao no prot´otipo ´e cerca de 2,5 vezes maior que o tempo de simula¸c˜ao da descri¸c˜ao algor´ıtmica. Isso se deve ao fato de tal descri¸c˜ao ser bastante abstrata e executar numa m´aquina hospedeira operando a uma freq¨uˆencia muito mais alta que a da plataforma-alvo.
22
6
Conclus˜
oes e perspectivas
Os resultados experimentais d˜ao claras evidˆencias da corretude e da robustez do IP projetado, cuja funcionalidade foi validada submetendo-o a um milh˜ao de est´ımulos gera-dos aleatoriamente.
Ademais, os resultados permitem estimar um limite inferior para o ganho de produ-tividade potencial obtido com a utiliza¸c˜ao de n´ıveis mais abstratos de modelagem. Por exemplo, para o Criptocore, o ganho de produtividade da simula¸c˜ao entre os n´ıveis fun-cional e RT ´e cerca de 5. O ganho de produtividade total ´e provavelmente bem maior, considerando-se a maior dificuldade de codifica¸c˜ao e depura¸c˜ao da descri¸c˜ao RT.
O Criptocore encontra-se validado e pretende-se disponibiliz´a-lo ao dom´ınio p´ublico no futuro pr´oximo. Para isso, ser´a preciso submetˆe-lo a um processo de certifica¸c˜ao preliminar `a sua integra¸c˜ao em reposit´orio de dom´ınio p´ublico, como por exemplo o do Projeto BrazilIP[7] ou o do Projeto ArchC[8], vers˜ao 2.0.
A prototipagem do Criptocore concorreu no ˆambito da Segunda Olimp´ıada Brasileira da Altera, tendo obtido a terceira coloca¸c˜ao. Um artigo[16] escrito a partir deste trabalho foi publicado em [17]
23
Referˆ
encias
1 WOLF, W. H. Computers as components: principles of embedded computing system design. [S.l.]: Morgan Kaufmann, 2001.
2 KO¸c C¸ etin K. RSA Hardware Implementation. [S.l.], 1995.
3 HOORNAERT, F.; GOUBERT, J.; DESMEDT, Y. Efficient hardware implementation of the des. In: Advances in Cryptology: Proceedings of CRYPTO 84. [S.l.: s.n.].
4 ELBIRT, A. J. et al. An FPGA implementation and performance evaluation of the AES block cipher candidate algorithm finalists. In: AES Candidate Conference. [s.n.], 2000. p. 13–27. Dispon´ıvel em: <citeseer.ist.psu.edu/elbirt99fpga.html>.
5 BUNIMOV, V.; SCHIMMLER, M. In: . [S.l.: s.n.].
6 AMANOR, D. N. Efficient Hardware Architectures for Modular Multiplication. Disserta¸c˜ao (Mestrado) — The University of Applied Sciences Offenburg, Germany, 2005.
7 BRAZILIP. Dispon´ıvel em: <http://www.brazilip.org.br>.
8 THE ArchC Architectural Description Language. Dispon´ıvel em: <http://www.archc.org>.
9 KNUTH, D. E. The Art of Computer Programming, Volume 2 / Seminumerical Algorithms. [S.l.]: AAAddison-Wesley publishing company, 1969.
10 SYSTEMC Community. SystemC Home Page. Dispon´ıvel em: <http://www.systemc.org>.
11 CORPORATION, A. NIOS I manual. [S.l.], March 2004.
12 CORPORATION, A. Avalon Bus Specification Reference Manual. [S.l.], March 2004. 13 GNU. Dispon´ıvel em: <http://www.gnu.org>.
14 ALTERA Corporation. Dispon´ıvel em: <http://www.altera.com>.
15 CORPORATION, A. APEX 20K Programmable Logic Device Family Data Sheet. [S.l.], March 2004.
16 FERNANDES, C. R. T. et al. Criptocore: projeto, valida¸c˜ao e prototipa¸c˜ao de um ip para aplica¸c˜oes criptogr´aficas. In: XII Workshop IBERSHIP. [S.l.: s.n.], 2006. v. 12. 17 XII Workshop IBERSHIP.
24
Anexo
Anexo A - C´
odigo fonte.
/∗ ∗ ∗ main . cpp ∗ ∗ D e s c r i ¸c ˜a o a l g o r´ıt m i c a . ∗/ #include <s y s t e m c . h> #include ” s t i m g e n . h” #include ”modexp . h” #include ” m o n i t o r . h” #include <i o s t r e a m > i n t s c m a i n ( i n t a r g c , char∗ a r g v [ ] ) { s c f i f o < unsigned i n t > X ( 1 ) ; s c f i f o < unsigned i n t > Y ( 1 ) ; s c f i f o < unsigned i n t > M( 1 ) ; s c f i f o < unsigned i n t > Q( 1 ) ;
MODEXP modexp ( ”modexp” ) ; modexp . x i n (X ) ; modexp . y i n (Y ) ; modexp . m in (M) ; modexp . q o u t (Q) ; STIMGEN s t i m g e n ( ” s t i m g e n ” ) ; s t i m g e n . x o u t (X ) ; s t i m g e n . y o u t (Y ) ;
6.0 Anexo A - C´odigo fonte. 25 s t i m g e n . m out (M) ; MONITOR m o n i t o r ( ” m o n i t o r ” ) ; m o n i t o r . q i n (Q) ; t i m e t t b u f f e r = t i m e (NULL ) ; s c s t a r t ( − 1 ) ; c o u t << ” t i m e : ”<< t i m e (NULL) − t b u f f e r << e n d l ; return 0 ; } /∗ ∗ ∗ s t i m g e n . h ∗ ∗ D e s c r i ¸c ˜a o a l g o r´ıt m i c a . ∗/ #i f n d e f STIMGEN H #define STIMGEN H #define SIZE ( i n t ) 1000000 #include <s y s t e m c . h> SC MODULE(STIMGEN) { s c f i f o o u t < unsigned i n t > x o u t ; s c f i f o o u t < unsigned i n t > y o u t ; s c f i f o o u t < unsigned i n t > m out ; void e x e c u t e ( ) ; SC CTOR(STIMGEN) {
6.0 Anexo A - C´odigo fonte. 26 SC THREAD( e x e c u t e ) ; } } ; #endif /∗ ∗ ∗ s t i n g e m . cpp ∗ ∗ D e s c r i ¸c ˜a o a l g o r´ıt m i c a . ∗/ #include ” s t i m g e n . h” #include <f s t r e a m . h> #include <i o s t r e a m . h> void STIMGEN : : e x e c u t e ( ) { i f s t r e a m t e s t B e n c h ( ” t e s t b e n c h . num” , i o s : : i n ) ; unsigned i n t x , y , m; f o r ( i n t i = 0 ; i < SIZE ; i ++) { t e s t B e n c h >> x ; t e s t B e n c h >> y ; t e s t B e n c h >> m; x o u t . w r i t e ( x ) ; y o u t . w r i t e ( y ) ; m out . w r i t e (m) ; } t e s t B e n c h . c l o s e ( ) ; } /∗ ∗ ∗ modexp . h ∗
6.0 Anexo A - C´odigo fonte. 27 ∗ D e s c r i ¸c ˜a o a l g o r´ıt m i c a . ∗/ #i f n d e f MODEXP H #define MODEXP H #include <s y s t e m c . h> SC MODULE(MODEXP) { // I n p u t d a t a ( x ˆ y mod m) s c f i f o i n < unsigned i n t > x i n ; s c f i f o i n < unsigned i n t > y i n ; s c f i f o i n < unsigned i n t > m in ; // Output d a t a s c f i f o o u t < unsigned i n t > q o u t ; void e x e c u t e ( ) ;
i n t modMul ( unsigned i n t x , unsigned i n t y , unsigned i n t m) ; SC CTOR(MODEXP) { SC THREAD( e x e c u t e ) ; s e n s i t i v e << x i n . d a t a w r i t t e n ( ) ; s e n s i t i v e << y i n . d a t a w r i t t e n ( ) ; s e n s i t i v e << m in . d a t a w r i t t e n ( ) ; } } ; #endif /∗ ∗ ∗ modexp . cpp ∗ ∗ D e s c r i ¸c ˜a o a l g o r´ıt m i c a . ∗/ #include ”modexp . h” #include <i o s t r e a m . h>
6.0 Anexo A - C´odigo fonte. 28 void MODEXP : : e x e c u t e ( ) { while ( true ) { i n t mask = 1 ; unsigned i n t r = 1 ; unsigned i n t x = x i n . r e a d ( ) ; unsigned i n t y = y i n . r e a d ( ) ; unsigned i n t m = m in . r e a d ( ) ; f o r ( i n t i = ( s i z e o f ( i n t ) ∗ 8 ) − 1 ; i >= 0 ; i −−) { r = modMul ( r , r ,m) ; i f ( ( ( y >> i ) & mask ) == 1 ) { r = modMul ( r , x ,m) ; } } q o u t . w r i t e ( r ) ; w a i t ( ) ; } } i n t MODEXP
: : modMul ( unsigned i n t x , unsigned i n t y , unsigned i n t m) { i n t mask = 1 ; unsigned i n t p = 0 ; unsigned i n t l ; f o r ( i n t i = ( s i z e o f ( i n t ) ∗ 8 ) −1; i >= 0 ; i −−) { p = 2∗p ; l = ( ( x >> i ) & mask ) ∗ y ; p = p + l ;
6.0 Anexo A - C´odigo fonte. 29 while ( p >= m) { p = p − m; } } return p ; } /∗ ∗ ∗ monitor . h ∗ ∗ D e s c r i ¸c ˜a o a l g o r´ıt m i c a . ∗/ #i f n d e f MONITOR H #define MONITOR H #include <s y s t e m c . h> SC MODULE(MONITOR) { s c f i f o i n < unsigned i n t > q i n ; void e x e c u t e ( ) ; SC CTOR(MONITOR) { SC THREAD( e x e c u t e ) ; s e n s i t i v e << q i n . d a t a w r i t t e n ( ) ; } } ; #endif /∗ ∗ ∗ monitor . cpp
6.0 Anexo A - C´odigo fonte. 30 ∗ ∗ D e s c r i ¸c ˜a o a l g o r´ıt m i c a . ∗/ #include ” m o n i t o r . h” #include <f s t r e a m > void MONITOR : : e x e c u t e ( ) { o f s t r e a m f i l e ( ” m o d e x p r e s u l t s . t x t ” ) ; while ( true ) { f i l e << ” r e s u l t : ” << q i n . r e a d ( ) << e n d l ; } } /∗ ∗ ∗ main . cpp ∗ ∗ D e s c r i ¸c ˜a o f u n c i o n a l ∗/ #include <s y s t e m c . h> #include ” s t i m g e n . h” #include ”modexp . h” #include ” m o n i t o r . h” #include <i o s t r e a m > i n t s c m a i n ( i n t a r g c , char∗ a r g v [ ] ) { s c f i f o < u f i x e d > X ( 1 ) ; s c f i f o < u f i x e d > Y ( 1 ) ; s c f i f o < u f i x e d > M( 1 ) ; s c f i f o < u f i x e d > Q( 1 ) ; STIMGEN s t i m g e n ( ” s t i m g e n ” ) ; s t i m g e n . x o u t (X ) ;
6.0 Anexo A - C´odigo fonte. 31
s t i m g e n . y o u t (Y ) ; s t i m g e n . m out (M) ;
MODEXP modexp ( ”modexp” ) ; modexp . x i n (X ) ; modexp . y i n (Y ) ; modexp . m in (M) ; modexp . q o u t (Q) ; MONITOR m o n i t o r ( ” m o n i t o r ” ) ; m o n i t o r . q i n (Q) ; t i m e t t b u f f e r = t i m e (NULL ) ; s c s t a r t ( − 1 ) ; c o u t << ” t i m e : ”<< t i m e (NULL) − t b u f f e r << e n d l ; return 0 ; } /∗ ∗ ∗ s t i m g e n . h ∗ ∗ D e s c r i ¸c ˜a o f u n c i o n a l ∗/ #i f n d e f STIMGEN H #define STIMGEN H #define SIZE ( i n t ) 3 #include <s y s t e m c . h> typedef s c u f i x e d < 3 2 , 3 2 , SC TRN , SC WRAP, 0 > u f i x e d ; SC MODULE(STIMGEN) {
6.0 Anexo A - C´odigo fonte. 32 s c f i f o o u t < u f i x e d > x o u t ; s c f i f o o u t < u f i x e d > y o u t ; s c f i f o o u t < u f i x e d > m out ; void e x e c u t e ( ) ; SC CTOR(STIMGEN) { SC THREAD( e x e c u t e ) ; } } ; #endif /∗ ∗ ∗ s t i m g e n . cpp ∗ ∗ D e s c r i ¸c ˜a o f u n c i o n a l ∗/ #include ” s t i m g e n . h” #include <f s t r e a m . h> #include <i o s t r e a m . h> void STIMGEN : : e x e c u t e ( ) { i f s t r e a m t e s t B e n c h ( ” t e s t b e n c h . num” , i o s : : i n ) ; unsigned i n t x , y , m; f o r ( i n t i = 0 ; i < SIZE ; i ++) { t e s t B e n c h >> x ; t e s t B e n c h >> y ; t e s t B e n c h >> m; x o u t . w r i t e ( x ) ;
6.0 Anexo A - C´odigo fonte. 33 y o u t . w r i t e ( y ) ; m out . w r i t e (m) ; } t e s t B e n c h . c l o s e ( ) ; } /∗ ∗ ∗ modexp . h ∗ ∗ D e s c r i ¸c ˜a o f u n c i o n a l ∗/ #i f n d e f MODEXP H #define MODEXP H #include <s y s t e m c . h> typedef s c u f i x e d < 3 2 , 3 2 , SC TRN , SC WRAP, 0 > u f i x e d ; SC MODULE(MODEXP) { // I n p u t d a t a ( x ˆ y mod m) s c f i f o i n < u f i x e d > x i n ; s c f i f o i n < u f i x e d > y i n ; s c f i f o i n < u f i x e d > m in ; // Output d a t a s c f i f o o u t < u f i x e d > q o u t ; void e x e c u t e ( ) ; u f i x e d modMul ( u f i x e d x , u f i x e d y , u f i x e d m) ; SC CTOR(MODEXP) { SC THREAD( e x e c u t e ) ;
6.0 Anexo A - C´odigo fonte. 34 s e n s i t i v e << x i n . d a t a w r i t t e n ( ) ; s e n s i t i v e << y i n . d a t a w r i t t e n ( ) ; s e n s i t i v e << m in . d a t a w r i t t e n ( ) ; } } ; #endif /∗ ∗ ∗ modexp . cpp ∗ ∗ D e s c r i ¸c ˜a o f u n c i o n a l ∗/ #include ”modexp . h” void MODEXP: : e x e c u t e ( ) { while ( true ) { u f i x e d r = 1 ; u f i x e d x = x i n . r e a d ( ) ; u f i x e d y = y i n . r e a d ( ) ; u f i x e d m = m in . r e a d ( ) ; f o r ( i n t i = 32 −1; i >= 0 ; i −−) { r = modMul ( r , r ,m) ; i f ( y [ i ] == 1 ) { r = modMul ( r , x ,m) ; } } q o u t . w r i t e ( r ) ; w a i t ( ) ; } }
6.0 Anexo A - C´odigo fonte. 35 u f i x e d MODEXP: : modMul ( u f i x e d x , u f i x e d y , u f i x e d m) { u f i x e d p = 0 ; u f i x e d l ; u f i x e d two = 2 ; f o r ( i n t i = 32 −1; i >= 0 ; i −−) { p = two ∗p ; l = x [ i ] ∗ y ; p = p + l ; while ( p >= m) { p = p − m; } } return p ; } /∗ ∗ ∗ monitor . h ∗ ∗ D e s c r i ¸c ˜a o f u n c i o n a l ∗/ #i f n d e f MONITOR H #define MONITOR H #include <s y s t e m c . h> typedef s c u f i x e d < 3 2 , 3 2 , SC TRN , SC WRAP, 0 > u f i x e d ; SC MODULE(MONITOR) { s c f i f o i n < u f i x e d > q i n ;
6.0 Anexo B - Artigo 36 void e x e c u t e ( ) ; SC CTOR(MONITOR) { SC THREAD( e x e c u t e ) ; s e n s i t i v e << q i n . d a t a w r i t t e n ( ) ; } } ; #endif /∗ ∗ ∗ monitor . cpp ∗ ∗ D e s c r i ¸c ˜a o f u n c i o n a l ∗/ #include ” m o n i t o r . h” #include <f s t r e a m > void MONITOR : : e x e c u t e ( ) { o f s t r e a m f i l e ( ” m o d e x p r e s u l t s . t x t ” ) ; while ( true ) { f i l e << ” r e s u l t : ” << q i n . r e a d ( ) << e n d l ; } }
Anexo B - Artigo
1
CRIPTOCORE: PROJETO, VALIDAÇÃO E PROTOTIPAÇÃO DE UM IP
PARA APLICAÇÕES CRIPTOGRÁFICAS
Carlos R. T. Fernandes, Gabriel R. Laureano, Luiz F. P. Santos, Luiz C. V. dos Santos
Departamento de Informática e Estatística Universidade Federal de Santa Catarina
Florianópolis, SC, Brasil
{carlosrf, laureano, penkal, santos}@inf.ufsc.br
ABSTRACT
The rise of SoCs was the result of two interacting factors: the increasing supply of hardware ruled by Moore’s Law and the demand of complex industrial applications, especially in the domains of consumer electronics and telecommunications. Platform-based design is the methodological response to the high costs of non-recurring engineering associated with contemporary technologies. Architectural reference, IP reuse and ESL are key mechanisms to cope with complexity and time-to-market. The need for productivity gains asks for IP models in different levels of abstraction. This paper describes the design, validation and prototyping of an IP in three distinct abstraction levels. The IP, called CriptoCore, implements modular exponentiation, a crucial operation used in important cryptographic applications. Experimental results give evidence of proper validation and allow the quantitative assessment of productivity gain.
1. INTRODUÇÃO
Systems-on-Chip (SoCs), que são sistemas dedicados de
hardware e software, surgiram da interação de dois fatores [1]: a crescente oferta de hardware ditada pela Lei de Moore e a demanda de aplicações cada vez mais complexas, especialmente nas áreas de eletrônica de consumo e de telecomunicações.
O projeto de SoCs baseado em plataforma [2] é uma resposta metodológica aos elevados custos de engenharia não-recorrente das tecnologias contemporâneas e consiste em uma arquitetura de referência e no reuso de blocos de propriedade intelectural (IPs).
A diminuição do ciclo de desenvolvimento de produtos eletrônicos e a pressão do time-to-market requerem ganhos de produtividade crescentes. Para isso, o projeto de SoCs deve iniciar-se em níveis de abstração cada vez mais altos. Um exemplo desta tendência na indústria de EDA (“Electronic Design Automation”) é a crescente
oferta de ferramentas em nível ESL (“Electronic System
Level”) para complemetar o fluxo de projeto
convencional, que se iniciava no nível RTL (“Register
Transfer Level”).
Assim, além dos vários requisitos impostos para garantir o reuso de IPs, faz-se necessário prover modelos de IPs em níveis mais abstratos que o RTL.
Este trabalho reporta o projeto, a validação e a prototipação de um IP em três níveis distintos de abstração. O IP denomina-se CriptoCore e implementa a exponenciação modular, uma operação crucial em importantes aplicações criptográficas.
A prototipação do CriptoCore concorreu no âmbito da Segunda Olimpíada Brasileira da Altera, tendo obtido a terceira colocação.
O restante deste artigo é organizado da seguinte forma. A Seção 2 revisa brevemente trabalhos correlatos. A Seção 3 descreve o projeto e a validação do IP, enquanto que a Seção 4 descreve sua prototipação. Os resultados experimentais são apresentados na Seção 5. A Seção 6 resume as conclusões e aponta direções para investigações futuras.
2. TRABALHOS CORRELATOS
Vários IPs para aplicações criptográficas são reportados na literatura [3, 4, 5]. A maior parte dos IPs implementa algoritmos criptográficos simétricos, tais como o DES [4] e o AES [5]. Há IPs que implementam operações freqüentemente utilizadas em algoritmos criptográfricos, como a exponenciação modular [3, 6].
Para realizar a exponenciação modular, todos os IPs encontrados pelos autores utilizam o algoritmo
Left-to-Right binary [3]. Por sua vez, para realizar a
multiplicação modular (operação primitiva utilizada pela exponenciação), a literatura reporta uma gama bastante extensa de algoritmos. Dentre os mais usados estão
2
Interleaved Standard Multiplication [6] e variações do
algoritmo de Montgomery [7].
No entanto, em sua grande maioria, os IPs são descritos apenas no nível RT e poucos são disponibilizados ao domínio público.
A carência de IPs de domínio público descritos em vários níveis de abstração motivou a proposta de repositórios orientados ao desenvolvimento de plataformas, tais como os dos projetos BrazilIP[8] e ArchC [9] (especialmente em sua iminente versão 2.0).
Este trabalho apresenta uma contribuição técnica na forma de um IP sintetizável, mas descrito em três diferentes níveis de abstração, a ser doado para repositórios públicos, tais como os acima citados.
3. PROJETO E VALIDAÇÃO DO IP 3.1. Metodologia de projeto
Foi adotada uma metodologia top-down [10], que consiste em descrever a funcionalidade do IP em um alto nível de abstração e, através de refinamentos sucessivos, descrever o IP em níveis de abstração cada vez mais baixos até que se obtenha uma descrição sintetizável. Neste trabalho, são usados os seguintes níveis de descrição: algorítmico, funcional com precisão de bits e RT.
3.2. Descrições do IP
O IP realiza a operação de exponenciação modular:
X
,
freqüentemente utilizada em aplicações criptográficas, tais como encriptação RSA, algoritmo de Diffie-Hellman e assinatura digital [11].
O IP possui três entradas (Base, Expoente e Módulo) e uma saída (Resultado).
Figura 1: Algoritmo para exponenciação modular
Para realizar a exponenciação modular, escolheu-se o algoritmo Left-to-Right binary, por ser o mais adequado à manipulação de números inteiros representados com um grande número de bits.
A Figura 1 descreve o algoritmo escolhido, onde P representa uma estimativa parcial da exponenciação modular a ser refinada iterativamente. Dada a representação binária do expoente e, seus bits são visitados do mais significativo (MSB) para o menos significativo (LSB), de forma que a estimativa corrente é elevada ao quadrado para cada bit visitado. A multiplicação modular é invocada somente se o bit visitado for “1”.
Para realizar a multiplicação modular no passo 2ada Figura 1 escolheu-se o algoritmo Standard Interleaved, por razões de praticidade.
A Figura 2 descreve o algoritmo escolhido, onde P representa uma estimativa parcial do produto modular. Dada a representação binária da base X, seus bits são visitados do MSB para o LSB, de forma que uma nova estimativa P é obtida a cada bit Xi visitado. Para obter
uma estimativa parcial, a idéia é intercalar multiplicação e módulo de maneira que os resultados intermediários sejam mantidos tão pequenos quanto possível. O passo 3 garante o correto alinhamento dos produtos parciais: o produto acumulado na iteração anterior é o dobro do produto parcial calculado na iteração atual, pois os bits são visitados do MSB para o LSB. O passo 4 realiza um produto parcial e o acumula. Os passos 5 e 6 aplicam a operação de módulo ao produto acumulado, dele subtraindo o valor M até se obter P < M.
Figura 2: Algoritmo para multiplicação modular
3.2.1 Descrição algorítmica
Neste nível o IP tem seu algoritmo implementado em alto nível. A comunicação entre os módulos e a representação interna dos números ainda não leva em conta efeitos de representação finita. As entradas e saídas do IP são modeladas em SystemC [12] através de canais do tipo FIFO. Sempre que é detectada a chegada de dados nas entradas, uma thread é disparada, a qual executa o
3 algoritmo da exponenciação modular. Após isso, o resultado é disponibilizado na saída.
3.2.2 Descrição funcional
Neste nível o módulo que representa o Criptocore já passa a ter precisão de bits, ou seja, a representação dos dados será feita com o número de bits que será efetivamente usado no sistema real. Essencialmente, a descrição funcional é um refinamento da descrição algorítimica em que a nova representação númerica é adotada.
3.2.3 Descrição RT
No nível RT, a estrutura do IP é descrita em termos de seus componentes básicos (tais como somador, registradores, deslocadores, etc.), os quais realizam o comportamento do algoritmo, dirigidos por uma unidade de controle. Esboços dos principais blocos do IP são apresentados nas Figuras 3 e 4.
A Figura 3 mostra os principais componentes do multiplicador modular. Vale ressaltar que o shifter implementa o passo 3 do algoritmo da Figura 2, enquanto o somador é usado para implementar os passos 5 e 7. O registrador armazena as estimativas parciais P da mutiplicação modular.
Figura 3: Estrutura do multiplicador modular
Por sua vez, a Figura 4 ilustra os principais componentes do exponenciador modular. O bloco ModMul encapsula o circuito da Figura 3, enquanto o
registrador armazena as estimativas parciais P da exponenciação modular.
Ao contrário das descrições anteriores, a comunicação entre os módulos é modelada através de sinais em SystemC. Por isso, novos canais foram criados para que a unidade de controle pudesse gerenciar a comunicação entre módulos.
Nesta fase de projeto, percebeu-se a necessidade de criar duas entradas e uma nova saída na interface: uma entrada para comandar o início de uma operação no IP, uma entrada para o clock e uma saída para sinalizar a disponibilidade do resultado.
Figura 4: Estrutura do exponenciador modular
3.2.4 Tradução para VHDL
Por não se dispor de uma ferramenta que sintetize uma descrição SystemC em nível RT, uma tradução manual para VHDL teve que ser feita. Como não há diferença conceitual entre as duas descrições, todos os canais e módulos mantiveram-se inalterados. Apenas mudanças sintáticas foram necessárias.
3.3. Metodologia de validação
Dois módulos adicionais foram criados para fazer a validação do IP. O módulo STIMGEN que lê valores em um arquivo e os repassa ao CriptoCore e o módulo MONITOR que salva os resultados gerados pelo CriptoCore num arquivo. A estrutura de validação é ilustrada na Figura 5.
4
Figura 5: Estrutura de módulos para validação
A descrição algorítmica é a implementação em alto nível do algoritmo que implementa a funcionalidade do IP. Por hipótese, assumimos a corretude da descrição algorítmica, para poder validar os demais. Um vetor de estímulos é aplicado ao modelo e seus resultados servem de referência para a descrição de nível inferior.
A partir da descrição funcional, cada descrição é submetida ao mesmo vetor de estímulos e seus resultados comparados com a descrição no nível imediatamente superior. Uma vez que o vetor de resultados é igual ao nível superior, a descrição é considerada validada. Os resultados produzidos pelo CriptoCore em todos os níveis de descrição foram exatamente os mesmos.
4. PROTOTIPAÇÃO 4.1. A plataforma de prototipação
A plataforma de que se dispunha para prototipação (veja Seção 5.2.1) permite o uso de um softcore, a CPU NIOS I, e a conexão de IPs é feita através do barramento AVALON. Para permitir a interação com a CPU, um
wrapper foi criado para o CriptCore, compatibilizando-o
com o protocolo daquele barramento.
4.2. Driver de acesso ao IP
Um driver de acesso ao CriptoCore foi construído para viabilizar sua interação com a CPU. Como o IP está diretamente conectado ao barramento, o driver consiste essencialmente na criação de ponteiros que representam o endereço associado ao CriptoCore no barramento. O
driver possui três métodos de acesso ao IP:
• init(int x, int y, int m): Inicia o IP com os valores passados como parâmetro.
• isReady(): Retorna 1 quando o resultado já está disponível na saída.
• getOutput(): Retorna o resultado da operação. Após a inicialização do CriptoCore, são necessários alguns ciclos de busy waiting, enquanto aguarda-se a disponibilidade do resultado, para então capturá-lo.
4.3. Restrições impostas pela plataforma-alvo
As descrições do CriptoCore nos três níveis de abstração adotados permitem a representação de valores com um número genérico n de bits. Preferencialmente, o número de bits deveria ser grande (e.g. n = 1024 bits) para uso em aplicações reais. Entretanto, considerando a exigüidade de
elementos lógicos na placa disponibilizada como plataforma-alvo, a representação adotada nas descrições restringe-se a n=32 bits, inclusive as entradas e saídas do IP. Note que esta é uma restrição imposta exclusivamente para fins de prototipação, sem perda da generalidade das descrições do CriptoCore.
5. RESULTADOS EXPERIMENTAIS 5.1. Experimentos através de simulação
5.1.1 Configuração
Todos os experimentos foram executados em um notebook Toshiba com processador Intel 1.7GHz, sob o sistema operacional Gentoo Linux (kernel-2.6.12). Para modelagem e compilação utilizaram-se SystemC-2.0.1 e GCC-3.3.5. As simulações VHDL foram feitas noa ferramenta Quartus-4.2.
5.1.2 Procedimento
Gerou-se um arquivo com 3 milhões de números aleatórios de 32 bits. Estes números servem de entrada para o módulo de estímulo, que irá atribuir o primeiro número do arquivo a X, o segundo a Y e o terceiro a M até que se esgotem os números do arquivo. Com isso o módulo que implementa o IP foi estimulado 1 milhão de vezes.
Figura 6: Complexidade das descrições
5.1.3 Resultados
Os resultados experimentais são ilustrados nas Figuras 6 e 7. A Figura 6 ilustra a complexidade das descrições em SystemC, expressa em número de linhas, enquanto a Figura 7 mostra os tempos de simulação das descrições em SytemC e o tempo de execução no protótipo.
Como esperado, os tempos de simulação aumentam à medida que o nível de abstração das descrições diminui.
Note que a simulação funcional é cerca de 56 vezes mais lenta que a algorítmica, embora não haja diferença sensível em sua complexidade. Isto se deve à utilização do tipo fixed point de SystemC para modelar os efeitos de
5 precisão finita. Note que a simulação no nível RT é cerca de 5 vezes mais lenta do que a simulação no nível funcional, dando uma evidência quantitativa do ganho de produtividade potencial ao se trabalhar em níveis mais altos de abstração.
Figura 4: Tempos de simulação/execução 5.2. Experimentos com o protótipo
5.2.1 Configuração
O CriptoCore foi implementado em uma plataforma de prototipação da Altera, modelo APEX20K [13]. A freqüência de relógio utilizada foi de 33MHz. Os dados de estímulo foram enviados à CPU NIOS através da porta serial da plataforma de prototipação.
5.2.2 Procedimento
Devido a uma dificuldade técnica de controlabilidade, não foi possível capturar o tempo do protótipo com exatamente os mesmo estímulos utilizados nas simulações. O tempo que aparece na Figura 7 é o tempo que o protótipo demorou para executar o mesmo número de operações do arquivo de estímulos usado nas simulações das descrições.
5.2.3 Resultados
Conforme ilustra a Figura 7, o tempo de execução no protótipo é cerca de 2,5 vezes maior que o tempo de simulação da descrição algorítmica. Isso se deve ao fato de tal descrição ser bastante abstrata e executar numa máquina hospedeira operando a uma freqüência muito mais alta que a da plataforma-alvo.
6. CONCLUSÃO E TRABALHOS FUTUROS
Os resultados experimentais dão claras evidências da corretude e da robustez do IP projetado, cuja funcionalidade foi validada submetendo-o a um milhão de estímulos gerados aleatoriamente.
Ademais, os resultados permitem estimar um limite inferior para o ganho de produtividade potencial obtido
com a utilização de níveis mais abstratos de modelagem. Por exemplo, para o CriptoCore, o ganho de produtividade da simulação entre os níveis funcional e RT é cerca de 5. O ganho de produtividade total é provavelmente bem maior, considerando-se a maior dificuldade de codificação e depuração da descrição RT.
O CriptoCore encontra-se validado e pretende-se disponibilizá-lo ao domínio público no futuro próximo. Para isso, será preciso submetê-lo a um processo de certificação preliminar à sua integração em repositório de domínio público, como por exemplo o do Projeto BrazilIP ou o do Projeto ArchC, versão 2.0.
A prototipação do CriptoCore concorreu no âmbito da Segunda Olimpíada Brasileira da Altera, tendo obtido a terceira colocação.
REFERÊNCIAS
[1] BERGAMASCHI, Reinaldo. A to Z of SoCs. Tutorial apresentado na Escola de Microeletrônica da SBC Sul (EMICRO 2002), Florianópolis, Brazil, 2002.
[2] SANGIOVANNI-VINCENTELLI, A., MARTIN, G, “Platform-Based Design and Software Design Methodology for Embedded Systems”. IEEE Design & Test of Computers, v. 18, n.6, p.23-33. November-December, 2001.
[3] KOç Çetin K. RSA Hardware implementation. [S.l], 1995. [4] HOORNAERT, Frank. GOUBERT, Jo. DESMEDT, Yvo.
Efficient Hardware Implementation of the DES. In: Advances
in Cryptology: Proceedings of CRYPTO 84. v. 196. p.147. 1985. [5] ELBIRT, AJ. YIP, W. CHETWYND, B. PAAR, C. An
FPGA Implementation and Performance Evaluation of the AES Block Cipher Candidate Algorithm Finalists.
[6] BONIMOV, M. S. V. Optimized Interleaved algorithm. In: The IEEE International Conference on Application-Specific Systems, Architectures, and Processors (ASAP’03). [S.l.: s.n.], 2003.
[7] AMANOR, D. N. Efficient Hardware Architectures for
Modular Multiplication. MSc. Dissertation — The University
of Applied Sciences Offenburg, Germany, 2005.
[8] BrazilIP.Disponível em http://www.brazilip.org.br
[9]The ArchC Architectural Description Language. Disponível em http://www.archc.org.
[10] WOLF, Wayne Hendrix. Computers as components:
principles of embedded computing system design. San
Francisco: Morgan Kaufmann, 2001.
[11] STALLINGS, William. Cryptography and network
security: principles and practice. 2nd ed. Upper Saddle
River: Prentice Hall, 1998.
[12] SystemC Community. SystemC Home Page, Disponível em: http://www.systemc.org. 2003.
[13] ALTERA. APEX 20K Programmable Logic Device
