Universidad de Costa Rica Facultad de Ingenier´ıa Escuela de Ingenier´ıa El´ ectrica

Implementaci´ on de controlador SDRAM para GPU THEIA

Por: Manuel Ruh Guevara

Ciudad Universitaria “Rodrigo Facio”, Costa Rica 12 de diciembre de 2014

Implementaci´ on de controlador SDRAM para GPU THEIA

Por: Manuel Ruh Guevara

IE-0499 Proyecto el´ ectrico Aprobado por el Tribunal:

Ing. Diego Valverde Garro Profesor gu´ıa

Ing. Marco Villalta Fallas Profesor lector

Ing. Harold Moreno Urbina Profesor lector

Resumen Este proyecto establece la base para el dise˜ no de un controlador de memoria SDRAM as´ı como la programaci´on del controlador de memoria utilizando el lenguaje de descripci´ on de hardware Verilog. Este controlador ser´a utilizado en conjunto con el GPU THEIA (desarrollado por el profesor Diego Valverde), utilizando una interfaz Wishbone, y ser´a implementado en la plataforma de desarrollo FPGA Papilio Pro. A pesar de que aplicaci´on mencionada anteriormente, el controlador no se limita a esta aplicaci´on, siendo posible utilizarlo en conjunto con otros dise˜ nos compatibles con Wishbone. En la primera secci´ on se desarrollan los conceptos te´oricos necesarios para el dise˜ no del controlador de memoria, y la implementaci´on del mismo en la plataforma de desarrollo Papilio Pro. La segunda secci´ on se enfoca en el dise˜ no del controlador de memoria a partir de una m´ aquina de estados, esta m´aquina se encarga de recibir y ejecutar todos los accesos a memoria solicitados por el sistema. Se incluyen tambi´en algunas simulaciones realizadas con un modelo funcional de la memoria provisto por el fabricante. Finalmente, la tercera secci´on busca validar las temporizaciones del controlador que debido a las limitaciones del modelo, no son validadas en la secci´on anterior. En particular se estudia la temporizaci´on de los ciclos de refrescamiento.

v

´Indice general ´ Indice de figuras

ix

´ Indice de cuadros

ix

1 Introducci´ on 1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2

2 Marco Te´ orico 2.1 FPGA . . . . . . . . . . . . . . . 2.2 Papilio Pro . . . . . . . . . . . . 2.3 Arquitectura de Memoria DRAM 2.4 DRAM sincr´ onico . . . . . . . . . 2.5 Controladores DRAM . . . . . . 2.6 Wishbone . . . . . . . . . . . . . 2.7 Procesador grafico THEIA . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

3 3 5 8 9 10 11 12

3 Dise˜ no 3.1 Generalidades a considerar . 3.2 Inicializaci´ on . . . . . . . . 3.3 Espera. . . . . . . . . . . . 3.4 Selecci´ on de fila. . . . . . . 3.5 Escritura . . . . . . . . . . 3.6 Lectura . . . . . . . . . . . 3.7 Relegaci´ on de fila . . . . . . 3.8 Refrescamiento . . . . . . . 3.9 S´ıntesis . . . . . . . . . . . 3.10 Wishbone . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

15 16 17 18 19 20 21 23 24 25 26

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

4 Validaci´ on 29 4.1 Validaci´ on de los ciclos de refrescamiento . . . . . . . . . . . . 29 5 Conclusiones y Recomendaciones 33 5.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2 Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Bibliograf´ıa

35 vii

A Acr´ onimos

37

viii

´Indice de figuras 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8

3.1

FPGA Spartan 6 [Gadget Factory, 2014]. . . . . . . . . . . . . . . Look-Up Table de dos entradas [Embeded Micro, 2014] . . . . . . Dise˜ no de la matriz de enrutamiento del FPGA Xilinx Spartan 6E Papilio Pro [Gadget Factory, 2014] . . . . . . . . . . . . . . . . . . Configuraci´ on LUT 6 . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitectura DRAM [Davis, 2001] . . . . . . . . . . . . . . . . . . Temporizaci´ on de SDRAM tomado de [Jacob et al., 2007] . . . . . Diagrama de conexi´on de Wishbone. Tomado de: (Opencores.org, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4 6 7 7 9 10 12

3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

Diagrama de bloques de la m´aquina de estados del controlador SDRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traducci´ on de direcciones GPU DRAM . . . . . . . . . . . . . . . Diagrama de temporizaci´on para inicializar la memoria . . . . . . . Diagrama de temporizaci´on selecci´on de fila. . . . . . . . . . . . . . Diagrama de temporizaci´on para escritura. . . . . . . . . . . . . . Diagrama de temporizaci´on para lectura. . . . . . . . . . . . . . . Diagrama de temporizaci´on para relegaci´on de fila. . . . . . . . . . Diagrama de temporizaci´on de un ciclo de refrescamiento. . . . . . Diagrama de lectura y escritura utilizando Wishbone. . . . . . . .

15 17 19 20 21 22 23 24 27

4.1 4.2 4.3 4.4

Diagrama de duraci´on del procedimiento de refrescamiento. . Diagrama de tiempo entre dos refrescamientos. . . . . . . . . Solicitud de lectura en el l´ımite antes de refrescamiento . . . Solicitud de lectura posterior al l´ımite antes de refrescamiento

. . . .

30 30 31 31

2.1

Tabla de la verdad de compuerta AND . . . . . . . . . . . . . . . .

5

3.1 3.2 3.3

Comandos de la memoria SDRAM utilizados por el controlador . . Resumen de los resutados de la s´ıntesis . . . . . . . . . . . . . . . . Utilizaci´ on de los recursos del FPGA . . . . . . . . . . . . . . . . .

16 25 26

. . . .

. . . .

´Indice de cuadros

ix

3.4

Equivalencias de las se˜ nales del controlador SDRAM y la interfaz Wishbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

x

26

1

Introducci´ on

En los u ´ltimos a˜ nos 30 a˜ nos las mejoras de eficiencia en los procesadores ha incrementado en gran manera la cantidad de datos que estos pueden procesar por cada unidad de tiempo. En contraste, los dispositivos de memoria, si bien es cierto han mejorado su rendimiento, en comparaci´on con los dispositivos de procesamiento se quedan muy por detr´as. Es por esta raz´ on que surge la necesidad investigar nuevas maneras para disminuir al m´ aximo la cantidad de interacciones entre estos dos dispositivos. El profesor Diego trabaja en esta optimizaci´on para su GPU THEIA, para lo cual requiere un ambiente para desarrollar modelos con el fin reducir los accesos a memoria. Se utiliza una plataforma Papilio Pro como el dispositivo para implementar el ambiente, esta plataforma cuenta con un FPGA y una memoria SDRAM en la misma tarjeta, por esta raz´on resulta ideal para poder desarrollar los modelos. Sin embargo para poder utilizar esta memoria, se requiere de un dispositivo encargado de controlar la memoria. En este trabajo se desarrolla el dise˜ no de un controlador de memoria SDRAM que funciona como interfaz entre el GPU THEIA y la memoria de la compa˜ n´ıa Micron modelo MT48LC4M16A2 presente en la plataforma Papilio Pro. La necesidad de un controlador surge debido a la complejidad para operar una memoria SDRAM, esta complejidad proviene de la gran cantidad de estados que presenta una memoria de este tipo, por ejemplo para realizar una lectura o una escritura, su direccionamiento se realiza en dos partes, primero se selecciona una fila y luego se lee o escribe la columna deseada, sin embargo se podr´ıa dar el caso en el que la fila sobre la cual se quiera leer o escribir se encuentre previamente seleccionada. Por otro lado debido al dise˜ no de las memorias SDRAM (cuyo bloque unitario posee un capacitor), la memoria debe de restaurar sus datos almacenados en intervalos peri´ odicos de tiempo. Es por esta raz´ on que resulta muy complicado para un GPU realizar operaciones directamente sobre la memoria SDRAM, la soluci´on a esta problem´atica proviene de la creaci´ on de un m´odulo intermediario llamado controlador de memoria, este es el encargado de llevar a cabo todas las operaciones necesarias para la inicializaci´ on, lectura, escritura y refrescamiento de la memoria, ofreciendo una interfaz similar a aquella de una memoria RAM est´atica. 1

2

1 Introducci´on

1.1

Objetivos

Objetivo General Implementar, documentar y verificar un controlador SDRAM para el Proyecto libre GPU THEIA.

Objetivos Espec´ıficos. • Desarrollar la implementaci´on del controlador de memoria en el HDL verilog • Implementar al menos un escenario de pruebas sencillo para verificar el correcto funcionamiento del controlador de memoria • Escribir una documentaci´ on del dise˜ no que incluya diagramas de tiempo y estados.

2

Marco Te´ orico

2.1

FPGA

FPGA son las siglas en ingl´es para Field Programable Gate Array, un FPGA es un dispositivo semiconductor capaz de reacomodar internamente sus compuertas para generar distintos dise˜ nos a partir de un solo chip. Te´oricamente el FPGA puede realizar la misma funci´on que har´ıa un ASIC (Chip con aplicaci´ on espec´ıfica) siempre y cuando la cantidad de compuertas requeridas por el ASIC sea menor que la cantidad de compuertas disponibles en el FPGA. Para programar un FPGA es posible hacerlo por medio de un lenguaje de descripci´ on de hardware como Verilog o VHDL. A continuaci´ on se menciona algunas de las ventajas y desventajas de utilizar un FPGA en lugar de un ASIC. Ventajas: 1. Se puede utilizar un mismo FPGA para implementar diversos dise˜ nos, esto ayuda a reducir costos. 2. Los costos de dise˜ no para bajo volumen son menores que la contraparte ASIC. 3. Facilita la depuraci´on de un dise˜ no. Desventajas: 1. Los FPGA son menos eficientes tanto en velocidad como en consumo de energ´ıa 2. ASIC son una soluci´on m´as barata para producci´on en masa. Para explicar la manera en que operan estos dispositivos se introducen tres t´erminos: Look-Up Tables (LUT), flip-flops y matriz de enrutamiento, estos tres componentes son los que le permiten al FPGA crear m´ ultiples dispositivos con solo programarlos. [Embeded Micro, 2014] 3

4

2 Marco Te´orico

Figura 2.1: FPGA Spartan 6 [Gadget Factory, 2014].

Look-Up Tables Los LUT (Look Up Table por sus siglas en ingl´es) son la manera en que se implementa la l´ ogica. Consiste en una cierta cantidad de entradas y salidas. Las salidas del LUT pueden ser programadas para que establecer cu´al debe ser la salida ante una determinada entrada. Una LUT consiste en un bloque de RAM el cual es indexado por las entradas del LUT, as´ı, la salida del LUT ante una entrada espec´ıfica ser´a el valor contenido en la posici´ on de memoria indicada por el valor de la entrada. De esta manera un LUT puede convertirse en cualquier funci´on l´ogica. Por ejemplo, si tuvi´eramos un LUT de dos entradas y una salida, como la que se muestra en la figura 2.2, y se quisiera programar una compuerta AND, el contenido de la RAM se deber´ıa ver como en el cuadro 2.1

Figura 2.2: Look-Up Table de dos entradas [Embeded Micro, 2014]

2.2. Papilio Pro

5 Direcci´ on (In[1:0]) 00 01 10 11

Valor (Out) 0 0 0 1

Cuadro 2.1: Tabla de la verdad de compuerta AND

Flip-Flops y Slices Cada LUT puede estar conectado a un flip-flop. Un grupo de LUT y flipflop es llamado slice. Los flip-flop son t´ıpicamente configurables permitiendo establecer el tipo (s´ıncrono, as´ıncrono) y el nivel (alto o bajo) de reset. Algunos otros inclusive pueden ser configurados como latches, sin embargo esto no es una buena pr´ actica debido a que puede generar problemas de temporizaci´on.

Matriz de enrutamiento La matriz de enrutamiento est´a compuesta por dos partes, la matriz de conmutaci´ on y los recursos generales de enrutamiento. La matriz de conmutaci´on se encarga de definir las l´ıneas sobre las cuales una unidad l´ogica va a estar conectada, mientras que los recursos de enrutamiento se encargan de llevar las se˜ nales de un bloque a otro. [Xilinx, 2010] Los recursos de enrutamiento son, en esencia, un grupo de cables y multiplexores que definen la interconexi´on entre bloques l´ogicos, entradas y salidas. Estas interconexiones est´an definidas por una memoria RAM, es por esta raz´ on, cada vez que se desconecta la alimentaci´on del FPGA es necesario reprogramarlo nuevamente. Esta sistema de interconexiones son la raz´on por la cual el FPGA es un sistema tan flexible, sin embargo esto tambi´en hace que el FPGA sea una soluci´ on m´ as lenta y menos eficiente en t´erminos de potencia que el ASIC asociado. La figura 2.3 muestra un esquema de la matriz de enrutamiento del FPGA Xilinx Spartan 6E.

2.2

Papilio Pro

Papilio Pro es una plataforma de desarrollo FPGA basada en el chip Xilinx Spartan 6 LX. Tiene 48 l´ıneas de entrada y salida, USB de doble canal, un programador JTAG integrado y una memoria SDRAM de 64Mb. En la figura 2.4 se puede observar la plataforma Papilio Pro. [Gadget Factory, 2014]

6

2 Marco Te´orico

Figura 2.3: Dise˜ no de la matriz de enrutamiento del FPGA Xilinx Spartan 6E

El Spartan 6 LX es un chip desarrollado con un proceso de 45 nm capaz de operar a 1 V (para bajo consumo) y 1.2 V (para alto rendimiento). Esta versi´on cuenta con 1430 slices, cada slice posee 4 LUT y 8 flip-flop. Los bloques l´ ogico configurable (CLB) en el Spartan-6 consiste en dos slices que forman columnas de dos elementos, existen tres tipos de CLB en la arquitectura del Spartan-6: SLICEM, SLICEL y SLICEX, cada una con cuatro LUTS, y ocho Flip-Flops. SLICEM corresponde a un 25 % de todos los slices, estos slices pueden ser configurados ya sea como un solo LUT de 6 bits de entrada y una sola salida, o como dos LUT de 5 bits de entrada que comparten entradas, y un bit adicional para la selecci´on de la l´ogica (Ver Figura 2.5) Los slices pueden utilizarse tambi´en como: memoria RAM distribuida de 64/32bit o como un registro de corrimiento de 32/16-bit. Adem´as para operaciones aritm´eticas, estos slices poseen propagaci´on de acarreo de alta velocidad a trav´es de columnas de slices. De igual manera los slices SLICEL corresponden al 25 % del total de slices del FPGA, tienen la misma estructura que los SLICEM, sin embargo estos no cubren la funcionalidad de RAM/Registro de corrimiento. Por u ´ltimo los SLICEX (50 % de los slices) tienen la misma estructura que los SLICEL pero

2.2. Papilio Pro

7

Figura 2.4: Papilio Pro [Gadget Factory, 2014]

Figura 2.5: Configuraci´on LUT 6

sin el acarreo para operaciones aritm´eticas. Papilio Pro incluye una memoria SDRAM Micron MT48LC4M16 la cual tiene un tama˜ no de palabra de 16 bits organizadas en 4 bancos de memoria con 4096 columnas y 256 filas cada una, para un total de 64 Mb de memoria. En total esta memoria posee 12 bits de direccionamiento y 2 bits m´as para seleccionar el banco de memoria donde se desea leer o escribir. En principio esta cantidad de bits de direccionamiento no son suficientes para poder direccionar en su totalidad la memoria, sin embargo como se mencion´o anteriormente la memoria est´a organizada en filas y columnas. Se utiliza un m´etodo de direccionamiento en dos pasos, y se aprovecha el concepto de r´afaga (Burst en ingl´es) para leer y escribir la memoria de manera m´as eficiente, el procedimiento utilizado es: [Micron, 2003] 1. Se debe establecer el registro de modo de operaci´on para definir el tama˜ no de la r´ afaga. 2. Se env´ıa un comando ACTIVE, la direcci´on indicada junto con este comando selecciona la fila y el banco que se va a leer o escribir. 3. Seguidamente se manda el comando READ o WRITE, en este caso las l´ıneas de direcci´ on son utilizadas para ubicar la columna la cual se va a

8

2 Marco Te´orico leer o escribir. De esta manera se comienza la r´afaga.

2.3

Arquitectura de Memoria DRAM

(University of British Columbia, 1996) DRAM proviene de las siglas en ingl´es para Memoria de acceso aleatorio din´amica, este tipo de memoria es popular por su simplicidad de construcci´on ya que solo se requiere un transistor y un capacitor, siendo este u ´ltimo el elemento que almacena el dato deseado. Debido a las caracter´ısticas inherentes del capacitor, existe una corriente de fuga que provoca la descarga del mismo, por este motivo es necesario refrescar los datos almacenados en todas las celdas de memoria, es por esta raz´on que a esta memoria se le acu˜ na la palabra “Din´amico” en el nombre. Las memorias DRAM se diferencian de las memorias SRAM (RAM Est´atica) ya que estas u ´ltimas tienen la capacidad de almacenar el dato indefinidamente mientras est´e debidamente energizada. Por otro lado DRAM se diferencia de otras tecnolog´ıas como flash en que las memorias flash pueden almacenar datos incluso cuando la energ´ıa ha sido interrumpida en el dispositivo. La mayor ventaja de las memorias DRAM es que son extremadamente eficientes en cuanto a costo/densidad. En la Figura 2.6 se ilustra la manera en que se organiza la memoria DRAM, todas las memorias DRAM poseen un arreglo de celdas de memoria los cuales son direccionados mediante los bits de fila. El direccionamiento se realiza mediante el esquema de filas y columnas. Para acceder a una posici´on de memoria se debe seleccionar primero la fila a la que se va a acceder y luego se escoge la columna, esto se hace a trav´es de las mismas l´ıneas de direcci´on. Para la multiplexaci´ on de la direcci´ on de filas y columnas la memoria cuenta con dos lineas extra: RAS* y CAS* (Row Address Strobe y Column Address Strobe, ambas se˜ nales activas en bajo), la primera para indicar que la direcci´on que se esta enviando es para la selecci´ on de fila y la segunda para seleccionar columna. De este modo la lectura y escritura de las memorias DRAM se divide en tres pasos: 1. Se debe seleccionar la l´ınea de lectura y escritura (R/W) seg´ un el acceso que se desea hacer, adicionalmente se debe poner el n´ umero de fila que se desea seleccionar en la l´ınea de direcciones. 2. Se debe esperar el tiempo de establecimiento (Set up) de RAS*, y activar la l´ınea de RAS* y luego esperar el tiempo de sostenimiento (Hold) de RAS* 3. Se debe poner la direcci´ on de columna en la l´ınea de direcci´on y el dato que se desea escribir en caso de que se est´e efectuando una escritura,

2.4. DRAM sincr´ onico

9

Figura 2.6: Arquitectura DRAM [Davis, 2001]

se debe esperar por el tiempo de establecimiento de CAS*, activar la l´ınea de CAS* y esperar el tiempo de hold, en el caso de una lectura, es posible leer el dato luego de cumplir con los tiempos de acceso de CAS* y RAS*.

2.4

DRAM sincr´ onico

Luego de diversas modificaciones simples hechas al esquema de DRAM asincr´onico, los esfuerzos se concentraron en crear una memoria sincr´onica (SDRAM). Esta memoria en lugar de ser gobernada en temporizaci´on por las se˜ nales de CAS* y RAS* (como s´ı suced´ıa en DRAM asincr´onico), introduce una se˜ nal de reloj. Esto provoca que las se˜ nales de CAS* y RAS* deban llegar en intervalos de tiempos regulares, alineado con el flancos creciente del reloj. Asi el comportamiento de temporizaci´on de la memoria es m´as predecible. [Jacob et al., 2007] Adicionalmente SDRAM incluye en su dise˜ no el concepto de r´afaga (burst) que permite el acceso a varias posiciones de memoria continuas m´as r´apidamente con solo un comando, esto se logra por medio de un contador que se utiliza para calcular la pr´oxima direcci´on, esto evita que sea necesario poner todas las direcciones en el bus de direcciones, de igual manera solo es necesario activar una sola vez la l´ınea de CAS*. Un registro programable en la SDRAM almacena el tama˜ no de la r´afaga que se va a leer o escribir (1, 2, 4, 8 palabras o p´ agina completa), la figura 2.7 muestra un ejemplo de la temporizaci´on de este tipo de memorias.

10

2 Marco Te´orico

Figura 2.7: Temporizaci´ on de SDRAM tomado de [Jacob et al., 2007]

Otro concepto introducido en las memorias SDRAM es que el tiempo de latencia de CAS o el tiempo que dura la memoria en poner datos en la salida desde que son solicitados, puede ser programado en el registro de modo de operaci´ on, el objetivo de esto es que la memoria sea compatible con otros chips de memoria de generaciones m´ as antiguas e incluso puedan ser integradas en un mismo m´ odulo.

2.5

Controladores DRAM

El objetivo de un controlador de memoria DRAM es hacer una interfaz entre la memoria y los procesadores, perif´ericos que se comuniquen directamente con la memoria e incluso procesadores gr´aficos. Los controladores tienen fuertes implicaciones en la manera en que se desempe˜ ne la memoria, se puede dise˜ nar un controlador por ejemplo para mejorar rendimiento o consumo de energ´ıa. [Altera, 2014] Una pregunta que podr´ıa surgir es, ¿Por qu´e son necesarios los controladores de memoria?, en esencia los controladores de memoria son necesarios por la complejidad y la gran cantidad de estados presentes en una memoria DRAM, es debido a esto que un CPU o GPU no es apto para manejar las transacciones hacia la memoria y se dise˜ na un dispositivo independiente. Como se explic´ o en la secci´ on anterior, para poder realizar una lectura o escritura de una memoria es necesario seguir varios pasos, algunos de estos pasos podr´ıan ser omitidos si se dieran las condiciones necesarias, de manera que los tiempos de acceso no ser´ıan los mismos en todos los casos. Por ejemplo considereses el caso en el que se desea leer una posici´on de memoria, si la fila a la cual pertenece dicha celda ya estaba seleccionada no toma m´as que unos pocos ciclos de reloj para poder tener el dato requerido en la salida. Sin em-

2.6. Wishbone

11

bargo si fuese necesario cambiar de fila, existe una limitaci´on temporal, debido a la naturaleza destructiva de la lectura de una fila (Los capacitores se descargan), hay que esperar cierto tiempo desde el momento en que se selecciona la fila para poder asegurar que los datos fueron almacenados nuevamente y finalmente hacer el cambio fila. Es trabajo del controlador garantizar que se cumplan estos tiempos, adem´ as de ser posible aprovechar este tiempo de espera ya que a´ un cuando no se puede cambiar de filas, es posible realizar operaciones sobre la fila seleccionada mientras se cumple la limitaci´on de tiempo. Por lo tanto el controlador debe recibir solicitudes de acceso y debe ser capaz de asignar prioridades. Otra optimizaci´ on que podr´ıa hacer el controlador es conocida como intercalaci´ on (interleaving en ingl´es). La intercalaci´on consiste en tener filas activas en m´ ultiples bancos de memoria con el objetivo de poder estar realizando lecturas consecutivas mientras se cumplen los tiempos necesarios. Por ejemplo si se debe cambiar una fila en un banco de memoria, se pueden enviar comandos a los otros bancos de memoria y extraer datos de ellos mientras se cumple los tiempos m´ınimos requeridos. En resumen, el controlador es un dispositivo encargado de recibir peticiones del procesador hacia el procesador, generar filas ordenadas de peticiones y traducir dichas peticiones a los comandos de la memoria y finalmente debe contener una l´ ogica de secuenciaci´on para garantizar las limitaciones de tiempo de la memoria.

2.6

Wishbone

Wishbone es una metodolog´ıa de dise˜ no cuyo prop´osito es fomentar la reutilizaci´ on de dise˜ nos evitando problemas de integraci´on. Esto se logra creando una interfaz com´ un entre los m´odulos de un dise˜ no. Esto mejora la portabilidad y confiabilidad de un dise˜ no y el tiempo de salida al mercado del producto. [Opencores, 2010] Wishbone busca solventar la problem´atica de esquemas de interconexi´on no est´ andar que dificultan la integraci´on de los dispositivos, proporcionando una l´ ogica personalizada para conectar cada uno de los bloques de un dise˜ no. Al adoptar una interconexi´on est´andar resulta m´as r´apido y f´acil la integraci´on de bloques del dise˜ no. Wishbone tiene tres partes fundamentales: las interfaces MASTER y SLAVE, y el m´ odulo SYSCON encargado de manejar las se˜ nales de reloj y reset del sistema. Wishbone posee una gran cantidad de opciones que pueden o no estar presentes en una interfaz en particular. La Figura 2.8 muestra el diagrama de interconexiones de un bus Wishbone.

12

2 Marco Te´orico

Figura 2.8: Diagrama de conexi´ on de Wishbone. Tomado de: (Opencores.org, 2010)

2.7

Procesador grafico THEIA

THEIA es una unidad de procesamiento de gr´aficos por vectores multin´ ucleo y multihilo. La idea de este proyecto es proveer un ambiente ?open source? o de c´odigo libre que incluya RTL (Nivel de transferencia de registro), ambientes de bancos de prueba o ?test bench? y un lenguaje/compilador c´odigo abierto, de alto nivel para la programaci´ on del GPU llamado “T-Language” El GPU esta descrito usando RTL escrito en el HDL Verilog 2001. Para poder realizar una simulaci´ on completa del RTL, el modelo de HDL requiere una serie de archivos de entrada que representan los par´ametros y la representaci´on del binario del c´ odigo de usuario. La salida de la simulaci´ on de RTL son una serie de archivos de log y una representaci´ on gr´ afica de la imagen representada en un formato que puede ser abierto utilizando un software standard para editar im´agenes como GNU Gimp. La arquitectura del GPU THEIA es dise˜ nada para ser eficiente para tareas relacionadas con gr´ aficos 3D, sin embargo debido a la flexibilidad de este sistema y del ambiente de programaci´on, existen una gran cantidad de aplicaciones que se pueden beneficiar del esquema de procesamiento vectorial y procesamiento en paralelo. THEIA combina procesamiento vectorial y ejecuci´on fuera de orden, para poder obtener paralelismo a nivel de instrucciones, ya que al ejecutarlos

2.7. Procesador grafico THEIA

13

operaciones vectoriales como instrucciones fuera de orden, la dependencias entre datos pueden ser minimizados y se puede obtener una mejor eficiencia. [Valverde, 2012]

3

Dise˜ no

El dise˜ no del controlador de memoria se realiza dividiendo la operaci´on completa del controlador de memoria en peque˜ nas tareas, a partir de estas tareas se crea una m´ aquina de estados para la implementaci´on. La figura 3.1 muestra el diagrama de estados que se utiliz´o para crear el primer dise˜ no. La siguiente secci´ on expone algunas de las generalidades a tener en cuenta para entender los diagramas de temporizaci´on de cada uno de los estados. Seguidamente se explica en detalle cada uno de los estados y se muestra un diagrama de temporizaci´ on del mismo.

Figura 3.1: Diagrama de bloques de la m´aquina de estados del controlador SDRAM 15

16

3 Dise˜ no Valor 0x0 0x1 0x2 0x3 0x4 0x5 0x7

Comando MRS AUTO REFRESH PRECHARGE ACTIVE WRITE READ NOP

Descripci´on Carga el registro de modo de operaci´on Realiza un ciclo de refrescamiento de los capacitores Relega la fila seleccionada Selecciona una fila Escribe en memoria Lee de memoria No realiza ninguna operaci´on

Cuadro 3.1: Comandos de la memoria SDRAM utilizados por el controlador

3.1

Generalidades a considerar

Convenciones acerca de las se˜ nales Para iniciar se explica la nomenclatura de las se˜ nales de salida y entrada del controlador de memoria, este posee en total 12 puertos de salida, 7 puertos de entrada y 1 puerto que puede funcionar tanto como entrada o salida. Los nombres de dichos puertos son: clk, DRAMAddr, DRAMBa, DRAMCas n, DRAMCke, DRAMClk, DRAMCs n, DRAMDq, DRAMDqm, DRAMRas n, DRAMWe n, iwAddress, iwData in, iwData mask, iwReq read, iwReq write, orData out, orData out valid, stall y rst. Todos los puertos que comienzan con el prefijo DRAM corresponden a puertos que van hacia la memoria SDRAM. De esta manera, el puerto DRAMAddr es el bus de direcciones, DRAMBa corresponde a la selecci´on de banco, DRAMClk y DRAMCke, corresponden respectivamente al reloj de la memoria y al habilitador del reloj, el reloj de la memoria tiene la particularidad de estar retrasado 2 ns con respecto al reloj del sistema, esto se implementa de esta manera para garantizar que se cumplan los tiempos de establecimiento de las se˜ nales. DRAMDq y DRAMDqm corresponden al bus de datos y a su respectivas mascaras. Por u ´ltimo las l´ıneas DRAMCs n, DRAMRas n, DRAMCas n y DRAMWe n son los puertos por donde se pasan los comandos, a lo largo de este trabajo estos puertos se agrupan en con ese mismo orden de significancia para formar un Bus de comandos “CMD”. En la tabla 3.1 se muestra una lista de los posibles valores en hexadecimal que puede tomar este bus de comandos y su respectivo significado: Las dem´ as se˜ nales son se˜ nales que van hacia el GPU (o de la interfaz Wishbone), en donde clk, rst y todas las dem´as se˜ nales que comienzan con el prefijo “iw ” corresponden a las entradas. De este modo iwAddress es el bus de direcciones, iwData in y iwData out son los buses de datos de entrada y salida correspondientemente, iwData mask, corresponde a las m´ascaras para utilizar

3.2. Inicializaci´ on

17

Figura 3.2: Traducci´on de direcciones GPU DRAM

en la lectura o escritura. Finalmente iwReq read iwReq write, son las l´ıneas por las cuales la interfaz Wishbone indica si hay que efectuar una lectura o escritura correspondientemente. Entre las salidas tenemos todas las que inician con el prefijo “or ” en donde orData out es el bus por medio del cual se le envian los datos al GPU, mientras que orData out valid es el encargado de ratificar la validez de dichos datos. Tambi´en tenemos el puerto stall, este le indica al GPU si el controlador de memoria es capaz de recibir otra solicitud de lectura o escritura.

Traducci´ on de las direcciones. Para poder realizar el direccionamiento de la memoria (escoger fila, columna y banco), se requieren en xtonces el bit menos significativo de la columna no es requerido ya que este se calcula internamente en la memoria. El objetivo de este apartado es establecer el m´etodo de traducci´on por el cual el controlador obtiene las direcciones que utiliza en la memoria. Anteriormente se me ncion´ o que el controlador recibe la direcci´on que el GPU quiere acceder por medio del puerto iwAddress. El controlador toma los dos bits m´as significativos y los asigna al banco, los siguientes 12 bits (del 18 al 7) los asigna a la fila, y por u ´ltimo los 7 bits menos significativos (del 6 al 0) los asigna a la parte alta de la columna, al bit menos significativo de la columna se le asigna el valor 0. En la figura 3.2 se puede observar un ejemplo de la traducci´on de direcci´ on.

3.2

Inicializaci´ on

Para la inicializaci´ on de la memoria MT48LC4M16A2 se requiere, seg´ un la hoja de fabricante, seguir m´ ultiples pasos para llegar al estado de espera. Los pasos citados por la hoja de fabricante son [Micron, 2003] 1. Se debe energizar el dispositivo. 2. Se debe cambiar y mantener en bajo la l´ınea de CKE 3. Garantizar que el reloj de la memoria es estable y cumple con todos los requerimientos de temporizaci´on

18

3 Dise˜ no 4. Se debe esperar al menos 100 us antes de realizar un comando diferente a NOP 5. En alg´ un punto de esos 100 us se debe cambiar CKE a su valor alto. 6. Una vez terminados los 100 us se debe hacer un comando de Precarga cuidando que se cumpla con el tiempo requerido tRP (se deben realizar comandos luego de la precarga) para establecer todos los bancos en un estado de espera. 7. Se debe realizar un comando de Auto refrescamiento, cumpliendo con el requerimiento de tiempo tRFC (definido por el fabricante), se deben realizar comandos NOP luego del auto refrescamiento para cumplir con este tiempo. 8. Se debe repetir el paso n´ umero 7 al menos una vez m´as. 9. Una vez terminado los auto refrescamientos se debe programar el registro de modo de operaci´ on. Para hacer esto se debe realizar un comando LMR (Load Register Mode). Se debe esperar el tiempo tMRD (definido por el fabricante) antes de poder realizar otro comando. Durante este tiempo se realizan Comandos NOP.

La figura 3.3 Muestra el diagrama de temporizaci´on provisto por el fabricante para la inicializaci´ on de la memoria (Figura 14 de la hoja de fabricante Rev. R 9/12 EN) Para la carga del registro de modo de operaci´on se debe de realizar un comando LRM, el valor a cargar debe estar presente en el bus de direcci´on de la memoria al momento de realizar el comando. Para el caso del presente dise˜ no se establece el registro con el valor binario 000000100001. El valor cargado establece que el dise˜ no trabajara en r´afagas de dos lecturas/escrituras, esto nos es de particular utilidad pues el bus de datos del sistema es de 32 bits contra el bus de datos de la memoria que es de 16 bits. Otro efecto que tiene ese valor del registro es que establece la latencia CAS en 2 ciclos, esto nos es de utilidad pues disminuye la latencia con la que se pueden accesar los datos. Para m´ as informaci´ on acerca de c´omo escribir en el registro o del significado de cada uno de los bits del mismo se puede referirse a la hoja de fabricante (Figura 15 de la hoja de fabricante).

3.3

Espera.

Este es el estado en donde el controlador espera a que se d´e un requerimiento de lectura o escritura. En caso de no haber requerimiento de lectura o escritura

3.4. Selecci´ on de fila.

19

Figura 3.3: Diagrama de temporizaci´on para inicializar la memoria

la m´ aquina se queda en este estado. Por otro lado, si existiera la necesidad de hacer un refrescamiento la m´aquina de estados parte tambi´en de este estado.

3.4

Selecci´ on de fila.

Una vez que llega una solicitud de lectura o escritura en donde el sistema tiene que proveer la direcci´ on que desea accesar, la m´aquina de estados pasa a un estado en donde se realiza la selecci´on de la fila, en concreto. Este estado se puede completar en 3 ciclos de reloj como m´ınimo, en el primer ciclo se le pasa a la memoria la direcci´ on de fila que se desea accesar junto con el comando ACTIVE para realizar la selecci´on de la fila. Los siguientes dos ciclos se utilizan para cumplir el tiempo de selecci´on de fila tRCD que corresponde a 15 ns. El controlador recibe del sistema 21 bits para realizar el direccionamiento y ser´ a el encargado de realizar una traducci´on de la memoria requerida por el sistema a la direcci´ on de fila, columna y banco requerido por la memoria. La figura 3.4 muestra el diagrama de temporizaci´on de la selecci´on de fila. Como se puede observar entre las dos marcas en la figura 3.4, se encuentra un ciclo de selecci´ on de fila, inicialmente se env´ıa un comando ACTIVE por las l´ıneas de comando, y se le indica la fila que se desea accesar en el bus de direcci´ on. En este ejemplo desea accesar la fila 1 en el banco 1. Luego del comando ACTIVE se realizan dos comandos NOP para garan-

20

3 Dise˜ no

Figura 3.4: Diagrama de temporizaci´on selecci´on de fila.

tizar el tiempo tRCD. Mientras tanto, el bus de datos de la memoria SDRAM se mantiene en alta impedancia, esto porque despu´es de un comando de activaci´on de fila se puede realizar una lectura o una escritura.

3.5

Escritura

Una vez terminada la selecci´ on de fila, una de las posibles acciones que se puede realizar seguidamente es la escritura. Para el dise˜ no del controlador de memoria que funciona en conjunto con el GPU THEIA, nos es conveniente utilizar un bus de datos entre el GPU y el controlador de memoria de 32 bits, sin embargo el bus de datos de la memoria es de 16 bits, es por esta raz´on que la escritura se realiza en r´ afagas de dos. A la hora de realizar una escritura, el controlador debe proporcionar la primera direcci´ on de la columna en donde se va a guardar el primer dato, la l´ogica interna de la memoria calcula la siguiente direcci´on, debido a esto solo es necesario proveer direcci´ on de columna para la primera escritura. En la escritura, el controlador es el que toma control del bus de datos. En la figura 3.5 se muestra un ciclo de escritura. Como se observa el valor que se desea guardar en la memoria es el hexadecimal 0xCAFEDEAD como se muestra en la l´ınea de entrada del controlador llamada iwData in. El ciclo de escritura es completado en 3 periodos de reloj, durante el primer periodo de reloj se le env´ıa el comando WRITE a la memoria junto con la direcci´on de la primera columna y el banco en donde se va a escribir. Durante el segundo periodo de reloj se le pasa la segunda parte de la palabra de 32 bits, pero

3.6. Lectura

21

Figura 3.5: Diagrama de temporizaci´on para escritura.

en este caso se debe realizar un comando NOP, adicionalmente la direcci´on no es necesario proveerla. El u ´ltimo periodo de reloj se utiliza para cumplir con el tiempo tWR requerido por la memoria, este tiempo es el tiempo que transcurre entre la aparici´on del u ´ltimo dato en el bus de datos de la memoria, y la solicitud de relegaci´on de la fila. Luego de terminado el ciclo de escritura, debido a que ya no se necesitan la direcci´ on almacenada en los registros del controlador de memoria, se le indica al GPU que el controlador est´a listo para recibir otra solicitud.

3.6

Lectura

La otra posibilidad luego de que se termina el proceso de selecci´on de fila es la lectura de un dato previamente guardado. La lectura igual que la escritura se realiza en r´ afagas de dos debido a que como se explic´o en la secci´on anterior, el bus de datos del GPU hacia el controlador de memoria es de 32 bits. Nuevamente se utiliza el concepto de que el controlador solamente provee la parte baja de la direcci´ on, y la memoria es la encargada de calcular la siguiente direcci´ on. Para el caso de la lectura el controlador debe dejar el bus de datos de la memoria en alta impedancia, ya que es esta u ´ltima la que se encarga de tomar el control sobre el bus. Adem´as como se indica anteriormente, debido

22

3 Dise˜ no

Figura 3.6: Diagrama de temporizaci´on para lectura.

a que se est´ a trabajando con una latencia CAS de 2 periodos, no es hasta el tercer flanco positivo del reloj de la memoria desde que se env´ıa el comando de lectura que se tiene el primer dato solicitado. La figura 3.6 muestra un ciclo de lectura, esta lectura se hace a la misma direcci´ on correspondiente a la del ejemplo de la escritura. Como se puede observar el ciclo de lectura toma 4 periodos de reloj, sin embargo no es hasta el 5 ciclo de reloj que se tiene el dato correcto a la salida. Durante el primer periodo se realiza un comando READ y se le debe indicar el banco y direcci´ on de columna que se desea leer, en el segundo periodo de reloj ya no es necesario mantener almacenada en los registros la direcci´on, por lo que el controlador indica mediante su l´ınea de stall que se puede enviar otra solicitud de lectura o escritura, durante este periodo como se especific´o anteriormente no hay ning´ un dato presente en el bus de datos. En el tercer y cuarto ciclo de reloj se puede observar que ya hay presente datos en el bus de direcciones, luego un periodo despu´es se tiene el dato listo en el bus de datos del GPU, adem´as se le indica al GPU que el dato presente en el bus es el que solicito. Como se puede observar existe un retardo de un periodo de reloj desde el momento en que aparece el u ´ltimo dato proveniente de la memoria, y el momento en el que ambos datos est´an listos en el bus de datos del GPU, esto se debe a que antes de llegar al bus de direcciones, el dato pasa por un registro interno que es el encargado de capturar el dato que viene de la memoria.

3.7. Relegaci´ on de fila

23

Figura 3.7: Diagrama de temporizaci´on para relegaci´on de fila.

3.7

Relegaci´ on de fila

Luego de que se termina el ciclo de lectura o de escritura, es necesario realizar un comando PRECHARGE para regresar al estado de espera y realizar una nueva lectura o escritura. Este paso se puede hacer de dos maneras, una es realizando la lectura o escritura indic´andole a la memoria por medio del bit A10 del bus de direcciones que debe hacer el comando PRECHARGE de manera autom´ atica una vez que termina la lectura, la otra es realizar manualmente este comando. Para el dise˜ no del controlador de memoria, se prefiere hacerlo de manera manual ya que en una posible mejora del controlador, se puede hacer que se realice m´ as de un acceso a una misma fila, mejorando as´ı la tasa lectura y escritura. La figura 3.7 muestra el ciclo de relegaci´on de fila, como se puede observar este solo necesita un periodo de reloj. Para este estado, el comando que se debe solicitar es como se dijo anteriormente el de PRECHARGE, adicionalmente es importante recalcar que el bit A10 del bus de memoria de la memoria se pone en alto para solicitar la relegaci´on de todas las filas en todos los bancos de memoria.

24

3 Dise˜ no

Figura 3.8: Diagrama de temporizaci´on de un ciclo de refrescamiento.

3.8

Refrescamiento

Cada 64 ms se debe realizar un refrescamiento de los datos almacenados en los capacitores de la memoria, para esto se deben realizar 4096 ciclos del comando AUTO REFRESH. Para cumplir con este requerimiento el controlador de memoria implementa un contador que se basa en el reloj del sistema para llevar el control del momento en el que se requiere un refrescamiento. La figura 3.8 muestra un ciclo de refrescamiento, como se puede observar, este se compone de 7 periodos de reloj, en el primero se lanza el comando AUTO REFRESH y luego los 6 siguientes se env´ıa un comando NOP mientras se espera a que el dispositivo est´e listo para realizar el siguiente comando AUTO REFRESH. Para este procedimiento el estado de todas las dem´as entradas y salidas de la memoria (Aparte de la se˜ nal de reloj y el bus de comandos) es irrelevante, pues todo el proceso de refrescamiento lo lleva a cabo la memoria. Por otro lado en cuanto a la se˜ nal de stall no es necesario que este en alto, pues esta se˜ nal no indica si el dispositivo est´a o no ocupado, sino el prop´osito de esta se˜ nal es decirle al sistema si puede o no recibir una solicitud, sin importar si puede realizarla en el preciso momento en el que la recibe o no. En otras palabras, la l´ınea de stall podr´ıa subir cuando se encuentra en el periodo de refrescamiento si llegara una solicitud del sistema ya sea de lectura o escritura.

3.9. S´ıntesis

3.9

25

S´ıntesis

Parte del objetivo de este proyecto es crear un dise˜ no sintetizable para poder luego implementarlo en una el Spartan 6E del Papilio Pro. De modo que una vez obtenido el modelo de comportamiento del controlador, es necesario verificar si el c´ odigo es sintetizable, para esto utilizamos el sintetizador de Xilinx. Los resultados se muestran en la tabla 3.2 tomada del software que realiza la s´ıntesis. En esta tabla se muestra un resumen de la configuraci´on de la s´ıntesis y de los resultados de la misma.

SDRAMCtrl Project Project File: Module Name: Target Device: Product Version: Design Goal: Design Strategy: Environment: Parser Errors: Implementation State: Errors: Warnings:

Status (11/02/2014 - 13:41:03) ise.xise SDRAMCtrl xc6slx9-3tqg144 ISE 14.7 Balanced Xilinx Default (unlocked) System Settings No Errors Synthesized No Errors 28 Warnings (28 new)

Cuadro 3.2: Resumen de los resutados de la s´ıntesis

Como se puede observar no hay errores en la s´ıntesis, sin embargo hay 28 precauciones, 27 de estas corresponden a recortes de registro debido a que hay algunos de estos que fueron dise˜ nados m´as grandes de lo que realmente era necesario, es posible hacer caso omiso de estas avisos. La u ´ltima precauci´on tambi´en puede ser ignorada, ya que esta es debido a la cantidad de entradas y salidas del m´ odulo del controlador es demasiado grande para poder ser mapeadas a las entradas y salidas del FPGA, el sintetizador indica que hay una utilizaci´ on de m´ as del 100 % de los recursos, sin embargo cuando se realice la conexi´ on del controlador de memoria con el GPU solamente las salidas necesarias ser´ an mapeadas directamente con las salidas o entradas del FPGA, por lo tanto esta precauci´ on desaparecer´a permitiendo as´ı el mapeo del dise˜ no. La tabla 3.3 muestra la utilizaci´on de los recursos del FPGA para esta s´ıntesis. En esta tabla se puede apreciar la utilizaci´on mas del 100 % de los recursos de entrada y salida.

26

3 Dise˜ no Device Utilization Summary (estimated values) Logic Utilization Used Available Utilization Number of Slice Registers 158 11440 1% Number of Slice LUTs 240 5720 4% Number of fully used LUT-FF pairs 132 266 49 % Number of bonded IOBs 133 102 130 % Number of BUFG/BUFGCTRLs 1 16 6% Cuadro 3.3: Utilizaci´on de los recursos del FPGA

3.10

Wishbone

Implementar la interfaz Wishbone para el controlador de memoria a partir del dise˜ no creado hasta ahora resulta muy sencillo pues en su mayor´ıa el dise˜ no del controlador de memoria tiene un comportamiento similar al requerido por la interfaz Wishbone. De hecho, la mayor´ıa de l´ıneas coinciden en comportamiento, y solo tres l´ıneas hacen falta para cumplir el protocolo Wishbone, estas son: CYC I, WE I y STB I. Las tres se˜ nales son utilizadas por el dispositivo maestro para solicitar lecturas o escrituras. Para generar estas se˜ nales se utilizan las se˜ nales del controlador de memoria iwReq read y iwReq write. En el caso de que cualquiera de las dos se encuentre en alto, se debe poner en alto CYC I y STB I. WE I se pone en alto si se trata de una lectura. La tabla 3.4 muestra las equivalencias entre las se˜ nales del controlador de memoria y Wishbone. Controlador de memoria clk rst orData out iwData in iwAddress iwReq write iwReq read iwData mask orData out valid orOperationPending

Wishbone CLK I RST I DAT O DAT I ADR I CYC I & STB I &WE I CYC I & STB I & !WE I SEL I ACK O STALL O

Cuadro 3.4: Equivalencias de las se˜ nales del controlador SDRAM y la interfaz Wishbone En la figura 3.9 se muestra una operaci´on de escritura seguido de una

3.10. Wishbone

Figura 3.9: Diagrama de lectura y escritura utilizando Wishbone.

lectura, utilizando la interfaz Wishbone.

27

4

Validaci´ on

Una vez implementado el dise˜ no en verilog, se deben realizar la respectiva validaci´ on para garantizar que el controlador funciona de la manera esperada. Las pruebas en esta secci´on se realizan por medio del simulador iSim de Xilinx, junto con un modelo de comportamiento desarrollado por Micron de la memoria MT48LC16M16A2. Si bien esta no es la memoria para la cual se est´ a dise˜ nando, la u ´nica diferencia entre este modelo y el MT48LC4M16A2 presente en el Papilio Pro es la cantidad de filas en un solo banco de memoria que finalmente se traduce en que el bus de direcciones del modelo tiene un pin extra. El motivo por el cual este modelo es de gran utilidad es porque posee los mismos tiempos de acceso que la memoria del Papilio Pro, los mismos comandos y adem´ as sus pines son en su mayor´ıa compatibles (con excepci´on del pin extra de direcci´ on). La principal limitaci´on de este modelo es que no verifica que se realicen los ciclos de refrescamiento necesarios para el correcto funcionamiento de la memoria, sin embargo si se realiza una simulaci´on lo suficiente larga, se podr´ a observar que cada 64 micro segundos se realizan 4096 ciclos de refrescamiento que requiere la memoria.

4.1

Validaci´ on de los ciclos de refrescamiento

Debido a la limitaci´ on del modelo de Micron, es de gran importancia garantizar que los tiempos de refrescamiento se cumplen debidamente. Esto tiene dos implicaciones, la primera es que se deben cumplir exactamente 4096 ciclos de refrescamiento. En la secci´on de refrescamiento se mostr´o que un ciclo de refrescamiento requiere 7 periodos de reloj, en total para poder realizar los 4096 ciclos se requiere 28672 ciclos de reloj o 286720 nanosegundos, En la figura 4.1 se muestra el proceso de refrescamiento medido desde el primer comando de AUTO REFRESH hasta el NOP generado en el estado IDLE (ya que este estado forma parte del ciclo de refrescamiento). Como se puede observar se cumplen los 286720 nanosegundos, garantizando as´ı que hay exactamente 4096 comandos AUTO REFRESH. El otro aspecto a evaluar con respecto al refrescamiento de la memoria consiste en el intervalo de tiempo entre un refrescamiento y el siguiente, seg´ un la hoja del fabricante cada 64 milisegundos se debe hacer un refrescamiento. En la figura 4.2 se puede observar se mide el tiempo entre dos refrescamientos consecutivos, el resultado es exactamente 64 milisegundos. 29

30

4 Validaci´on

Figura 4.1: Diagrama de duraci´on del procedimiento de refrescamiento.

Figura 4.2: Diagrama de tiempo entre dos refrescamientos.

Finalmente con respecto al refrescamiento, el controlador de memoria tiene que garantizar que los tiempos de refrescamiento se cumplan, esto quiere decir que debe ser capaz de determinar si debe realizar o no una lectura o escritura dependiendo de cu´ anto tiempo le queda antes del siguiente refrescamiento, el peor de los casos en cuanto a estas dos operaciones se refiere es el de la lectura, que toma 90 nanosegundos para ser completado, si falta un tiempo menor para el siguiente proceso de refrescamiento entonces el controlador no debe empezar la operaci´ on de lectura o escritura. Las figuras 4.3 y 4.4 muestran las consecuencias de este caso. En la figura 4.3 se puede ver que la solicitud de lectura llega justo a tiempo para ser ejecutada antes del refrescamiento. Por el contrario en la figura 4.4 la se˜ nal llega un periodo de reloj tarde por lo que se debe esperar a que se realice todo el proceso de refrescamiento antes de ejecutar la lectura garantizando as´ı la integridad de los datos almacenados en la memoria SDRAM.

4.1. Validaci´ on de los ciclos de refrescamiento

31

Figura 4.3: Solicitud de lectura en el l´ımite antes de refrescamiento

Figura 4.4: Solicitud de lectura posterior al l´ımite antes de refrescamiento

5 Conclusiones y Recomendaciones 5.1

Conclusiones

• Se logr´ o implementar el RTL de un controlador de memoria funcional con la capacidad de realizar funciones simples de lectura y escritura individuales, este RTL se puede implementar en el Papilio Pro. • La interfaz Wishbone que facilita la integraci´on con el GPU THEIA se logr´ o implementar de manera sencilla a partir de l´ogica combinacional, y en algunos casos con solo realizar un mapeo directo entre los pines del controlador y la interfaz wishbone. • Se realizaron ambientes de pruebas con la ayuda de un modelo l´ogico de la memoria de Micron para garantizar que tanto la funcionalidad como la temporizaci´ on del controlador de memoria satisfacen los requerimientos. • Se escribi´ o la documentaci´on acerca del comportamiento de las salidas del controlador para cada una de las operaciones posibles, as´ı como los requerimientos de entrada y los respectivos diagramas de temporizaci´on para cada una de las operaciones del controlador de memoria.

33

34

5.2

5 Conclusiones y Recomendaciones

Recomendaciones

Una de las mejoras m´ as evidentes que se le puede hacer al controlador de memoria, es activar la capacidad de realizar m´ ultiples accesos a una sola fila sin la necesidad de realizar la selecci´on de la fila cada vez que se requiera escribir o leer datos en accesos consecutivos, esto generar´ıa una gran ganancia en desempe˜ no ya que se podr´ıa ahorrar m´ ultiples ciclos de reloj para accesos consecutivos de memoria. En el caso de la escriutura si existe el requerimiento de hacer una activaci´on de fila en total se requieren 7 ciclos de reloj, si se habilitara esta caracter´ıstica una lectura consecutiva podr´ıa durar 3 ciclos de reloj esto representa una mejora en tiempo de un 57 % de una lectura consecutiva con respecto a la lectura a una fila nueva. Por el otro lado la lectura consecutiva pasar´ıa de ser un procedimiento de 8 ciclos de reloj a uno de 4 mejorando en un 50 % el tiempo que dura la lectura. La otra posible mejora consiste en agregar una peque˜ na memoria al controlador SDRAM para poder mejorar la velocidad de transferencia de datos entre el GPU y el controlador de memoria, una vez implementado esto, y junto con la mejora anterior, se podr´ıa dar prioridad a los accesos a memoria que se realizan a una misma fila para de esta manera aprovechar el beneficio que la localidad espacial a la hora de realizar accesos de memoria. Realizar la implementaci´ on de esta mejora implicar´ıa tambi´en la implementaci´on de un sistema por el cual si el GPU realiza una transacci´on de lectura o escritura de un dato, una vez que el controlador de memoria termina con dicha transacci´ on, pueda indicarle que esa transacci´on fue satisfactoriamente realizada. Esto podr´ıa ser implementado utilizando las l´ıneas de etiqueta de presentes en el esquema de Wishbone.

Bibliograf´ıa Altera (2014). Dram controllers for system designers. http:// www.altera.com/technology/system-design/articles/2012/ dram-controller-system-designer.html. Recuperado en 9-9-2014. Davis, B. T. (2001). Modern DRAM Architectures. Embeded Micro (2014). How does an FPGA work? https://embeddedmicro .com/tutorials/mojo/how-does-an-fpga-work. Recuperado en 2-9-2014. Gadget Factory (2014). Papilio Pro. http://www.papilio.cc/index.php?n= Papilio.PapilioPro. Recuperado en 2-9-2014. Jacob, B., Ng, S. W., & Wang, D. T. (2007). Memory Systems Cache, DRAM, Disk. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc. Micron (2003). MT48LC4M16 SDRAM Datasheet. Opencores (2010). Wishbone B4. Valverde, D. (2012). Theia architecture specification. Xilinx (2010). Spartan-6 FPGA Configurable Logic Block. http://www .xilinx.com/support/documentation/user_guides/ug384.pdf.

35

A

Acr´ onimos

• GPU: Unidad de procesamiento gr´afico o en ingl´es Graphics Processing Unit. • FPGA: Arreglo programable de compuertas en campo (Field Programable Gate Array). • ASIC: Circuito integrado de aplicaci´on espec´ıfica (Aplication-Specific integrated circuit). • HDL: Lenguaje de descripci´on de Hardware. • VHDL: Son las siglas en ingl´es para VHSIC HDL o Very High Speed Integrated Circuit Hardware Description Language. • LUT: Tabla de b´ usqueda (Look-Up Table). • SRAM: Memoria de acceso aleatorio est´atica (Static Random Access Memory). • DRAM: Memoria de acceso aleatorio din´amica (Dynamic Random Access Memory). • SDRAM: Memoria de acceso aleatorio din´amica sincr´onica (Synchronous Dynamic RAM). • RAS* Y CAS*: Se˜ nal estrobosc´opica para la direcci´on de columna y fila de una memoria DRAM, esta se˜ nal es activa en bajo (Row/Column Address Strobe). • MT48LC4M16A2: Modelo de memoria SDRAM de Micron.

37