VERIFICACIN DE SISTEMAS DIGITALES

Identicacin y Caracterizacinde Cuellos de Botella en Arquitectura de Buses Utilizando la Aplicacin Simple_bus de SystemC
Wilson Ren Guevara Arvalo - 261397

AbstractThis paper presents a description of the nal proyect of the asignature "Verication of Digital Systems", it consists in an analisis made over the simple_bus example of SystemC, wich princial result is the detection of bottle-necks. The original arquitecture of Symple_Bus had been done with the ability of joining any quantity of masters and slaves communicating each other by a data bus. The rst step of this work was to measure the specic caracteristics of a conguration, these includes latency, throughput, use of the data bus and use per master. Secondly, it was implemented a bridge arquitecture allowing the connection of two buses at the same time and giving the capacity of comunicate masters and slaves of both buses. This part includes others characteristics like the measure of the bridges use. Once the elements was described and when the refered caracteristics are used, it was possible to recognize if there was bottle-necks or not. Index Termsdata bus, master, slave, bridge, latency, throughput, data bus use

TDMA (Time Division Multiple Access) Adems de la denicin de estos componentes de hardware, que fueron los utilizados en la arquitectura de bus simple_bus, existe una unidad de hardware denominada puente (bridge) y que se describe a continuacin. Un puente o bridge es un medio de comunicacin entre dos buses de datos, este trabaja pasiva y activamente, de tal forma que los maestros acceden a un bus preguntando por una posicin de memoria que se encuentra en otro bus. Debido a que el esclavo se encuentra en otra parte el bus, este pasa sus datos al puente, el cual pasa de su estado pasivo de memoria a un estado activo en el que envia peticiones al segundo bus y luego el proceso se invierte hasta que el dato llegue al maestro que lo requirio. II. T RABAJO P REVIO

I. I NTRODUCCIN Luso de buses de datos en arquitecturas de computadores y en sistemas embebidos en general es bastante amplio y permite la comunicacin entre diferentes componentes de hardware usando poco espacio. Al trabajar con buses de datos es posbile encontramos varios terminos como esclavos, maetros o arbitros, las deniciones de esos terminos se encuentran a continuacin. Los maestros son las unidades de procesamiento de un sistema, que piden son de tipo activo ya que piden acceso al bus para solicitar o enviar infomacin a una memoria. Las operaciones ejecutadas opr lo maestros pueden ser operaciones de lectura o de escritura que constan de una direccin y de un dato. Los esclavos son normalmente unidades de tipo pasivo que responden a las peticiones que circulan por un bus. Estas peticiones provienen de los maestros y le brindan informacin a los eclavos sobre la posicin a leer para que este emita un valor de respuesta. Un arbitro, consiste en un modulo que organiza el acceso al bus por parte de los maestros, este concepto tiene sentido en sistemas de comunicacin de ms de un maestro y dispone de varios metodos de arbitraje, estos consisten en la manera en que se decide que maestro accede al bus cuando varios de ellos desean comunicarse. Entre estos metdos de arbitraje tenemos: FIFO (First Input, First Output) Prioridades jas

Como punto de partida de este proyecto se tienen los codigos en systemC correspondientes al modelo symple_bus. Una rpida descripcin de esta arquitectura se presenta a continuacin. Tambien se presentar el trabajo realizado respecto a la medicin de las principales metricas de desempeo al implementar distintas metodologias de arbitraje. A. Simple Bus El modelado del bus que se realiza en SystemC es un modelado sencillo donde no se manejan conceptos como pipeline o divisin por transacciones. El modelo de symple_bus incluye la denicin de maestros y esclavos, a cntinuacin se pesenta una viion general del funcionamiento y una descripcin de los modulos esclavos y masters. Las funciones de lectura/escritura del bus se ejecutan en el anco de subida llamando la funcin burst_write/burst_read desde el maestro Blocking y la funcin write/read desde el non-blocking, alli se llama get_request para buscar la peticin de acuerdo a la prioridad, de no encontrarse se crea una nueva peticin con las caractersticas de lectura apropiadas. Cada vez que hay un anco de bajada el bus ejecuta su accin principal (main_action), la cual evala la siguiente peticin con get_next_request, aqu se observa la lista de peticiones y se le pide al arbitro que dena la siguiente a analizar, si la peticin actual no ha sido terminada aun, se continua su ejecucin sin requerir del arbitro. Para ser analizada una funcin debe estar en estado de SIMPLE_BUS_REQUEST o SIMPLE_BUS_WAIT.

VERIFICACIN DE SISTEMAS DIGITALES

Una vez se ha seleccionado la peticin a manipular con el get_next_request, se realiza la manipulacin de la peticin con handle_request. Esta funcin dene inicialmente el estado de la peticin a ocupado, e identica el esclavo que sera ledo o escrito. Dicho esclavo se lee o escribe con la funcin correspondiente write o read que este posee y su resultado denir el estado nal de la peticin. Si la peticin ha sido terminada ya sea como un SIMPLE_BUS_ERROR o SIMPLE_BUS_OK, se activa el evento transfer_done con el cual terminar la operacin de lectura. Existe un aspecto ms a tener en cuenta y corresponde a la accin principal del maestro, sea blocking o nonblocking, en ella se dene la cantidad de espacios o palabras en memoria a procesar (mylenght). De manera que en la funcin handle_request, si se ha terminado una operacin de lectura o escritura, aunque el estado de la peticin sea SIMPLE_BUS_OK, no se terminara la accin sino que se cambiaran las propiedades de direccin y dato a procesar para la siguiente palabra, esta accin depende directamente del tipo de maestro; si es blocking, no se liberara la peticin hasta que se termine todo el proceso de escritura o de lectura en todas las direcciones requeridas. Sin embargo, si es un maestro nonblocking se liberara la peticin una vez se halla escrito una sola posicin de memoria, tras la cual se enviar una nueva peticin. 1) Esclavos: Se manejan dos tipos de esclavos que se comportan como si fuesen memorias, dos clases denominadas simple_bus_fast_mem y simple_bus_slow_mem. Estas implementan una misma interfaz que les asigna funciones de lectura y escritura y que sern conectadas al bus a travs de puertos esclavos. La diferencia las dos memorias radica en que la memoria lenta requiere de un tiempo (en ciclos) especco para poder ser leda o escrita (variable m_nr_wait_states) mientras que la memoria rpida devuelve inmediatamente el dato que se desea procesar. Dependiendo de la manera en que se usen estos esclavos pueden tener un tamao especico y una velocidad determinada que les podra hacer simulaciones como si fuesen bien sea memorias CACHE , RAM, o memorias ms lentas como los discos duros. Existen dos funciones denidas tambin en la interfaz de los esclavos (simple_bus_slave_if) que permiten la lectura y escritura inmediatas, esto con el n de monitorear el estado de la memoria con un maestro (master_direct) sin uso real del bus. 2) Maestros: Se manejan tres tipos de maestros, de los cuales uno se comporta como un monitor (simple_bus_master_direct) y los dos restantes trabajan como generadores de trco. El maestro direct se implementa con el n de vericar la correcta escritura en las memorias o esclavos por parte de los maestros generadores de trco. Esto es debido a que los estos generadores de traco piden acceso al bus con el n enviar o recibir datos desde los esclavos a travs de operaciones de lectura y escritura. Un generador de trco puede ser de tipo Blocking o nonblocking, ambos ejecutan accin de lectura y de escritura de una determinada cantidad de datos de una direccin que

posteriormente ser direccionada por el bus hacia uno de los esclavos. Ac es claro que el bus acta como canal entre lo maestros y los esclavos permitiendo comunicarse a partir de puertos al canal que implementa las interfaces de lectura y escritura de cada maestro, estas interfaces son llamadas: simple_bus_direct_if, simple_bus_blocking_if, simple_bus_non_blocking_it. Es tambin claro que un generador de trco al acceder al bus no lo hace de manera instantnea y la adquisicin de datos provenientes de los esclavos no es directa como en el caso de maestro directo. Esto involucra el uso de peticiones (requests). III. D ESARROLLO Uno de los pasos a realizar a lo largo del proyecto fue a implementacin de un puente que se encargue de hacer comunicacin entre dos buses. El diseo del puente se basa en el funcionamiento de los esclavos, ya que este es accedido como un esclavo por parte de cualquiera de los buses, por esta razn implementan la interfaz simple_bus_slave. A pesar de esto, cuando el bus accede el puente le entrega los datos de su peticin y en el ciclo de bajada se activa una funcin de tipo main_action, cuya nalidad es enviar las petici es n necesarias al segundo bus de acuerdo a la direccin de la eticin requerida. El estado de las peticiones en el bus principal cambia, de manera que se crean dos nuevos estados, estos se describen a continuacin: SIMPLE_BUS_RETRY, este esado libera el uso del bus primario una vez que el puente adquiere lo datos, la peticion cambia al estado SIMPLE_BUS_AGAIN surnte el siguiente cicl de cubida en que se activo. SIMPLE_BUS_AGAIN, cuando la peticin llega a este estado, se mantiene el bus libre por un ciclo ms, luego del cual cambia a SIMPLE_BUS_WAIT, volviendo asi a hacer parte de la lisa de eticiones y a ser evaluada por el arbitro. Si una peticin pasa por los estados RETRY y AGAIN y an no se tiene el resultado en el puente, esta peticin regresar al esado RETRY. IV. S IMULACIONES Los siguientes items corresponden a algunas de las simulaciones realizadas con el n de caracterizar y comrobar el funcionamiento del puente realizado. Tambin se presentan los primeros resultados de topologias ms complejas. En este trabajo actualmente se esta comparando gracamente la forma en que el bus es usado ls buses de tal forma que se puede ver la interaccin entre ellos cuando se usa el puenteo. A. Funcionamiento Master Bloquing Esta prueba imlementa un nico maestro con una memoria con el n de caracterizar el comportamiento del maestro y como sus seales son procesadas. El uso del bus es de 66.72% en bus simple y 30.78%, 46.19% para dos buses con puente. Latencia 1 en ambos casos. Throughput 3.08 y 3.56 bits por ciclo.

VERIFICACIN DE SISTEMAS DIGITALES

Figure 1.

Funcionamiento del maestro tipo Bloquing

B. Funcionamiento Master Non-Bloquing Este es el mismo caso, pero para un modelo non-bloquing. Es importante ver como a travs del uso del puente las peticiones se discretizan y el porcentaje de uso del bus principal disminuye.
Figure 3. Diferentes topologias de dos maestros y dos esclavos

V. C ONCLUSIONES

Figure 2.

Funcionamiento del maestro tipo Non-Bloquing

El uso del bus es de 44.5% en bus simple y 22.88%, 34.32% para dos buses con puente. Latencia 1 en ambos casos. Throughput 2.37 y 3.66 bits por ciclo.

C. Pruebas anexas. 2MATERS (b-nb), 2SLAVES(s-s) Estas son las primeras pruebas usando el puente ara vaios maestros y memorias. En todos los casos el bus principal, considerado como el de mayor cantidad de maetros o ms exacamente, el de mayor cantidad de peticiones salientes por el puente, tiende a disminuir su pocentaje de uso dando la posibilidad de crear comunicaciones ms rapidas (de menor latencia).

En general, el uso del puente disminuye notablemente el uso de los buses mejorando asi problemas de cuello de botella cuando se usa un unico bus. Si el uso del bus es del 100 porciento es muy robable que se tenga un cuello de botella, al usar dos buses unido por un puente, el porcentaje de uso por bus tiende a ser menor y or tanto pueden dejar de existir esos picos. Pruebas anexas a las resentadas demuestran que si el segundo bus posee maestros con sus esclavs en dicho bus, el porcentaje de uso del primer bus aumenta, por lo que es importante conocer el bus de ms traco y evitar que el puente tenga que acceder a el como maestro. El uso de la herramienta SystemC para el estudio de modelos de dierentes sistema es muy amplio, permitiendo al programador aadir uncionalidades y dems facilmente. Aunque no se aadio, la forma de arbitraje usada resulta tambin de mucha importancia en el comortamiento de los buses. En este punto, el principal problema viene dado por el hecho de que la prioridad asignada a las peticiones provenientes del puente es la mas alta. Se requiere aumentar la cantidad de trabajo de esta parte, aunque se tiene un amplio inicio en el rea de caracterizaci del n puente.

El uso del bus es Simple 82.71% 77.5% 22.52% 4.27 caso1 59.16% 52.3% 47.7% 56.42% 4.07 caso2 76.45% 87.27% 12.73% 19.46% 2.67 caso3 66.53% 27.87% 72.13% 33% 4.39

Uso del primer bus Bloquing Non-bloquing Uso del segundo bus Througput

Latencia promedio de 13.2491 en el bus simple. Mximo de 9 en el caso 3.