Discussion

56

Este módulo al igual que en la ronda de encripción, se trata de compuertas X-OR entre la clave y el dato que se esté procesando según la ronda donde se encuentre el algoritmo.

5.3.2.

Módulo Inv_ByteSub

El módulo Inv_ByteSub al igual que en la encripción, se encarga de realizar una sustitución del dato que le ingresa a las memorias ROM, la única diferencia entre la encripción y la des-encripción, es que la tabla que se encuentra guardada en la ROM, es la tabla S-BOX invertida que se puede apreciar en la Figura 2.7.

5.3.3.

Módulo Inv_ShiftRows

El módulo Inv_ShiftRows al igual que en el módulo ShiftRows, se debe realizar las rotaciones sobre las filas que le indican la tabla 2.1, pero en este caso la rotación debe hacerse hacia la izquierda.

En esta implementación se realizó la rotación a la entrada de la función ByteSub, igual que se hizo en la encripción como se puede ver en la figura 5.5

5.3.4.

Módulo Inv_Mixcolumns

El transporte de datos para realizar la función Inv_Mixcolumns es igual a la de la función Mixcolumns que se encuentra en la figura 5.5, la diferencia está en el valor por el cual se realizan las multiplicaciones dentro de los sub-módulos.

5.3.4.1. Sub-Módulo Inv_Comb1

Las multiplicaciones que se realizan en el módulo Inv_Comb1 según la matriz Inv_MixColumns son [0E, 0B, 0D, 09], las multiplicaciones se pueden apreciar en la figura 5.20:

57

5.3.4.2. Sub-Módulo Inv_Comb2

El módulo Inv_Comb2 realiza las siguientes multiplicaciones según la matriz Inv_MixColumns [09, 0E, 0B, 0D], las multiplicaciones se pueden ver en la figura 5.21:

Figura 5.21 Sub-Módulo Inv_Comb2

5.3.4.3. Sub-Módulo Inv_Comb3

El módulo Inv_Comb3 realiza las siguientes multiplicaciones según la matriz Inv_MixColumns [0D, 09, 0E, 0B], las multiplicaciones se pueden apreciar en la figura 5.22:

58

5.3.4.4. Sub-Módulo Inv_Comb4

El módulo Inv_Comb4 realiza las siguientes multiplicaciones según la matriz Inv_MixColumns [0B, 0D, 09, 0E], las multiplicaciones se muestran en la figura 5.23:

Figura 5.23 Sub-Módulo Inv_Comb4

5.4.

Testbench

La finalidad de un testbench es de verificar el correcto funcionamiento de un diseño, dependiendo de la instancia del diseño en que nos encontremos el testbench puede hacerse más complejo o más sencillo, ya que simplemente se pueden generar los estímulos para verificar conexiones del diseño, o generar estímulos aleatorios e ir revisando las salidas de los puertos al mismo tiempo.

Para la primera parte de comprobación del funcionamiento del diseño, se implementó un testbench básico, que se puede apreciar su diagrama en la figura 5.24:

(a) Testbench Encripción (b) Testbench Des-Encripción Figura 5.24 Módulos Testbench

59

En la figura 5.24 se puede apreciar el Testbench para cada módulo, algo importante para resaltar es que en el Testbench las salidas son las entradas del módulo AES y las salidas del módulo AES son las entradas del Testbench, esto con el fin de que las señales o estímulos que genere el Testbench entren al módulo AES y que las salidas en respuesta a ese estímulo puedan ser verificadas por el mismo Testbench.

El primer test que se implementó tenía como objetivo estimular el circuito para ver que las conexiones entre los sub-módulos estuvieran funcionando y mirar la funcionalidad de los módulos de una manera visual, la simulación del módulo de encripción se puede ver en la figura 5.25:

En la figura 5.25 se encuentra la simulación del módulo de encripción AES, como todo el diseño es combinacional, la respuesta del módulo es inmediata, tal como se puede ver en la figura 5.25, los estímulos ingresados fueron los mismos ingresados en la implementación en C.

(a) (b) (c) Figura 5.25 Simulación Aes Encripción

60

Los resultados de la Encripción en RTL son iguales a los resultados obtenidos en el algoritmo en C, figura 5.25 y figura 5.2.

La simulación del test básico del módulo de des-encripción se puede apreciar en la figura 5.27:

Figura 5.27 Simulación Aes Des-Encripción

Los datos de entrada a esta simulación son la salida del módulo en encripción y la salida de este módulo es igual a los datos iniciales.

Conectando los dos módulos y simulándolos con el test básico obtenemos la figura 5.28:

Figura 5.28 Simulación Aes-128 Encripción y des-Encripción

En la figura 5.28 hallamos la salida encriptada y des-encriptada donde los datos iniciales son iguales a la salida des-encriptada.

La siguiente prueba fue con un testbench estructurado, del cual se puede apreciar su diagrama de bloques en la figura 5.29

61

La estructura del testbench se divide en varios módulos que cumplen determinada función dentro del proceso de verificación, la idea de este testbench es verificar la salida del módulo para ver que todos los paquetes que se encriptan están correctos.

El diseño del testbench utilizado fue:

 Módulo Test: genera las señales aleatorias para excitar el diseño o DUT  Módulo Driver: Es la clase donde se generan los objetos del TestBench  Módulo Tb: es el encargado de las interfaces del TestBench

 Módulo Top: es el encargado de la conexión del DUT con el TestBench  Módulo Checker: Revisa la salida del testbench vs. el diseño o DUT

En la figura 5.30 se puede apreciar la simulación de la encripción con un testbench generando señales aleatorias

Figura 5.30 Testbench Aleatorio Encripción

Es la figura 5.30 se puede apreciar que el TestBench genera las señales aleatoriamente, el último paso del Testbench es verificar que la salida del módulo se encuentra encriptando de forma correcta.

62

5.4.1.

Verificación

Para verificar el diseño se implementó dentro del Testbench el módulo en C que se diseñó al comienzo del trabajo de investigación, como el Testbench no es sintetizable, la implementación de códigos de alto nivel para verificar RTL es posible.

Para poder integrar el código en C al Testbench fue necesario hacer uso de DPI-C “Direct Programming Interface” que es la interface de comunicación entre el Testbench y las funciones en C, la manera de importar las funciones de C es la siguiente:

Import "DPI-C" function void import_func();

Esta función permite ejecutar funciones en C desde un Testbench, pero los valores que genera el código en C hay que enviarlos al Testbench para la verificación del RTL, para esto se utiliza la siguiente función:

Export "DPI-C" function export_func;

El Testbench se va a encargar de generar los estímulos para el DUT o el algoritmo de encripción y también para el código en C, para que luego el mismo Testbench se encargue de comparar los dos resultados y verificar el correcto funcionamiento del diseño.

Figura 5.31 Testbench Algoritmo Encripción

En la figura 5.31 está la estructura del Testbench donde el generador de estímulos alimenta al algoritmo en C y al RTL, estos estímulos pueden ser de orden aleatorios o también pueden ser de lectura de archivos u otros.

Para la primera parte de verificación se implementó un Testbench que generará estímulos aleatorios al algoritmo de encripción en RTL y en C como se puede apreciar en la figura 5.32:

63

Figura 5.32 Testbench Aleatorio módulo Encripción

Así, la figura 5.32 demuestra que hay una señal nueva que se llama AES_encrypted_from_C, esta señal es la salida del algoritmo de encripción en C, se puede apreciar en la figura que la salida del algoritmo es la misma que la salida del módulo en RTL AES_out_Enrypt.

Figura 5.33 Testbench aleatorio módulo des-encripción

La figura 5.33 permite apreciar el Testbench generando estímulos aleatorios del módulo de des-encripción.

Para estar seguros del funcionamiento conectado los dos módulos encripción y des- encripción en serie y poniendo a funcionar un test aleatorio sus resultado se puede ver detallado en la figura 5.33.

64

Figura 5.34 Testbench aleatorio de los módulos en serie.

Como se puede apreciar en la figura 5.34 los datos que entran al módulo de encripción son exactamente los mismos que salen por el módulo de des-encripción.

La prueba final del testbench para la verificación de los circuitos fue de la encripción y des-encripción de dos archivos de los cuales uno fue una imagen de tamaño de 20KB y el otro un archivo de texto de 28 KB, estos dos archivos se pueden apreciar en la figura 5.35.

(a) (b)

65

La intención al procesar un texto y una imagen, era estimular el circuito no solo con texto sino con datos diferentes para ver su funcionamiento y comportamiento en potencia y área, resultados que se ven reflejados el capítulo de análisis de resultados.

El testbench se encarga de llamar a la función en C que lee el archivo de entrada Import "DPI" function void leer_archivo();

Esta funcion se encarga de leer el archivo y de enviar los datos al testbench de manera que el circuito pueda entenderlos para encriptarlos o des-encriptarlos dependiendo el caso.

El archivo en C se encarga de guardar los datos de entrada en una matriz de n x 16 enviando al circuito los datos síncronos al reloj, para la encripción del archivo:

Figura 5.36 Testbench de lectura de imagen

Como se aprecia en la figura 5.36 las salidas AES_out_Encrypt y AES_encryted_from_C son iguales, pero la forma de garantizar que realmente sean iguales es analizándolas bit por bit, la estructura del test para verificar la encripción se puede ver en el siguiente código:

leer_archivo(); //ingresa el archivo a encriptar $display("SV: tamano %h",tamano); //tamaño del archivo

for(i=0;i<tamano;i=i++) begin

#1 envio_datos(i);

test_Aes_encriptor_completo(); // entrega la clave AES_Encrypt(estateSV,keySV); //Envialos datos a C

check; //compara los datos de C y SV

Este código lee el archivo a encriptar y dependiendo al número de datos realiza un for, donde le va entregando los datos al circuito y los va revisando con la función check que se puede ver a continuación:

66 Task check; int l; for(l=0;l<16;l++) begin if(Aes_encrypted_from_C[l]!=1'bx) begin

$fwriteh(fileC,Aes_encrypted_from_C[l]); //salida del modulo en C end

if(AES_out_Encrypt[l]!=1'bx) begin

$fwriteh(file,AES_out_Encrypt[l]); //salida del RTL end @(posedge clk); if(Aes_encrypted_from_C!=AES_out_Encrypt) begin error_count=error_count+1; end end endtask

El código anterior es la tarea que se encarga de escribir los datos que genera el código en C y el RTL en dos archivos .txt, también en la última parte compara las dos salidas de los módulos y en caso de ser diferentes suma un contador para notificarlo al final, en caso de que los archivos sean iguales, el test notifica que la encripción fue exitosa.

(a) (b)

67

La figura 5.37 permite apreciar los archivos generados por el RTL y el módulo de C, que deben ser iguales para que el test sea exitoso.