1

RC-Mock: Mocking Framework para moduloshardware generados mediante HLS

Julian Caba1, Fernando Rincon, Julio Daniel Dondo,Jesus Barba, Manuel Abaldea y Juan Carlos Lopez

Resumen—La fase de verificacion es una de las fasesmas importantes dentro del ciclo de vida de un pro-ducto, debido a que de ella depende en gran medida eltime-to-market del mismo. En los ultimos anos el flujode diseno hardware para sistemas basados en FPGAs(Field-Programmable Gate Arrays) ha evolucionadonotablemente, permitiendo el uso de lenguajes de al-to nivel para la descripcion de aceleradores hardware.Este avance ha permitido disminuir el esfuerzo reali-zado por los desarrolladores a la hora de implemen-tar sus disenos. Sin embargo, la etapa de verificacioncontinua siendo una tarea compleja de abordar, prin-cipalmente debido a que en la mayorıa de entornos deverificacion es necesario incluir componentes de ter-ceros.

Este trabajo propone como solucion el uso de doblesde prueba propuesto en las metodologıas de desarro-llo agil en un entorno puramente hardware, utilizandoun dispositivo fısico como plataforma de verificacionhardware. El framework de mocks propuesto en estetrabajo, RC-Mock, permite reemplazar la funcionali-dad de terceros dentro de un diseno HLS (High-LevelSynthesis) por un componente que imita el compor-tamiento real de ese tercero, eliminando del disenooriginal las dependencias. Esta verificacion sera rea-lizada en un dispositivo fısico con el fin de eliminarinexactitudes que introducen las herramientas HLSy reducir el tiempo que introduce la co-simulacion.Sobre el dispositivo logico reconfigurable o FPGA seha disenado una plataforma de verificacion hardwaredisponible remotamente permitiendo el despliegue dedisenos basados en FPGA y su posterior verificacioncon un framework de testing.

Palabras clave— verificacion, Field-ProgrammableGate Array, Test-Driven Development, dobles deprueba

I. Introduccion

La continua evolucion de los sistemas en chip(SoC) requiere de nuevas herramientas de diseno conel fin de reducir la brecha entre diseno y capacidadestecnologicas ofrecidas por estos tipos de dispositivos,ası como disminuir la complejidad del proceso de di-seno de hardware [1]. Un ejemplo de estas nuevasherramientas son las denominadas herramientas deSıntesis de Alto Nivel o HLS, que permiten a los in-genieros acelerar sus aplicaciones o construir sus pro-pios componentes utilizando lenguajes de programa-cion de alto nivel (HLL), como pueden ser C, C++ oSystemC. El uso de estas herramientas y de los HLLestan cada vez mas extendidos en el diseno hardwa-re, permitiendo trabajar en un nivel de abstraccionmas alto siempre que los requisitos lo permitan y nosea necesario un diseno manual de bajo nivel. Porlo tanto, el uso de estas herramientas permite a losingenieros construir modulos hardware a partir de al-goritmos software y realizar una exploracion del es-

1Universidad de Castilla-La Mancha, 13071 Ciudad Real,Espana, email: julian.caba@uclm.es

Accuracy

Eort

low high

low

high

Prototype

Emulation

HL

Modelling

RTL

Simulation

Timing

Simulation

Fig. 1: Relacion entre esfuerzo y precision referente a laverificacion

pacio de diseno en un tiempo reducido, disminuyendoel time-to-market del producto final [2].

Desafortunadamente, y a pesar de los avances enel diseno digital hardware, aun persiste una signifi-cativa brecha entre las capacidades tecnologicas y lasnecesidades de verificacion. Los ultimos estudios afir-man que la verificacion de hardware es el cuello debotella en la mayorıa de los proyectos, llegando a al-canzar hasta el 70 % del tiempo de desarrollo [3]. Es-ta situacion se agrava por el uso de las herramientasHLS debido a las limitaciones que estas presentan yque aun no han sido resueltas, como es la inclusion deun dispositivo fısico para completar el flujo de disenohardware. Incluir un dispositivo fısico proporcionauna serie de ventajas como puede ser la precision deresultados o la reduccion del tiempo de verificacionfrente al tiempo que requiere una co-simulacion [4].La parte negativa de introducir un dispositivo fısicocomo parte del proceso de verificacion es el aumentode la complejidad o esfuerzo que requiere. La Figu-ra 1 ilustra la relacion entre esfuerzo y precision dela verificacion hardware de acuerdo con el nivel deabstraccion. En la grafica se puede observar que elmenor esfuerzo de verificacion se obtiene utilizandomodelos de alto nivel, pero que normalmente con-llevan inexactitudes. En el lado contrario, se puedeobservar que el uso de un dispositivo fısico es el en-torno perfecto para el proceso de verificacion, peroesta tecnica requiere mayores esfuerzos por parte delos desarrolladores [5].

Otro aspecto a destacar son las dependencias conterceros, como pueden ser el uso de una memoria, uncomponente no disponible, etc. Estas dependenciasson un nuevo reto para los ingenieros de pruebas,puesto que deben ser incluidas en sus escenarios deverificacion con el fin de comprobar el comportamien-to del modulo en produccion. Una solucion propuesta

en el mundo software es el uso de dobles de prueba,de forma que aquellas partes de terceros son sustitui-das por componentes que simulan el comportamientoreal de terceros. Posteriormente, los dobles de prue-ba pueden ser interrogados para obtener informacionsobre el proceso de verificacion. Sin embargo, susti-tuir el comportamiento de estos terceros en hardwareno es nada sencillo y menos aun si se introduce undispositivo fısico como plataforma de verificacion.

En este trabajo, se propone un framework democks hardware como ampliacion del trabajo pre-vio realizado en [4], el cual se basa en tecnicas detesting software para modulos hardware generadoscon herramientas HLS. Nuestra propuesta consideracomo parte del proceso de verificacion el desplieguedel modulo en produccion en un dispositivo fısicopara eliminar inexactitudes introducidas por las he-rramientas HLS. Por lo tanto, proponemos una so-lucion a los desafıos relacionados con la validacionde sistemas, eliminando las dependencias de tercerosque presentan algunos disenos con el fin de construirun entorno de verificacion con el menor numero deentidades reales (dependencias). Para lograr nuestroobjetivo principal, nuestra propuesta proporciona lossiguientes aspectos:

Un nuevo framework de mocks hardware, RC-Mock, capaz de crear dobles de prueba hardwa-re, facilitando el proceso de verificacion sobredispositivos fısicos.Una plataforma fısica de verificacion para mane-jar el propio proceso de verificacion, permitiendosu configuracion desde el propio test.Una comunicacion transparente entre el test yel modulo en produccion y entre el test y el do-ble de prueba, es decir, desacoplar el frameworkpropuesto del diseno bajo prueba o DUT (De-sign Under Test).

El documento esta organizado de la siguiente for-ma. La segunda seccion introduce las caracterısticasde los test unitarios y define los dobles de prueba,listando sus tipos y justificando la eleccion de unode ellos. La seccion tercera muestra nuestra visionde componente hardware junto con la propuesta dedoble de prueba hardware aplicando esa vision decomponente hardware. La cuarta seccion describe laplataforma de verificacion hardware disenada y sobrela que se ha desplegado el caso de estudio presenta-do en la quinta seccion. Finalmente, la ultima seccionresume este documento y propone las lıneas futurasde este trabajo.

II. Dobles de prueba

Una propuesta para comprobar la validez de losdisenos implementados por los ingenieros es el usoo definicion de pruebas unitarias junto con otros ti-pos de pruebas. Las pruebas unitarias se relacionancon la tecnica de comprobar cierta funcionalidad denuestro diseno, esa funcionalidad generalmente se de-nomina unidad puesto que representa a la unidadmınima que puede ser probada, en software la uni-

dad mınima es un metodo, mientras que en hardwarese puede considerar una unidad funcional (Functio-nal Unit, FU ) como la unidad mınima a probar. Lavalidez de la unidad se determina de acuerdo a lacomparacion entre el resultado esperado y el resulta-do producido por la esta tras inyectarle un conjuntode estımulos. Estas pruebas unitarias deben cumplirvarias caracterısticas que se recogen en la conocidaregla FIRST [6]: Fast, las pruebas deben ser lo sufi-cientemente rapidas para no convertirse en un cuellode botella; Independent, una prueba no debe depen-der de otras pruebas; Repeatable, la prueba debedevolver los mismos resultados independientementede las veces que se ejecute; Self-validation, la pruebadebe devolver un resultado booleano (pasar o fallar)sin ninguna interpretacion subjetiva y; Timely, laspruebas unitarias deberıan ser escritas justo antesdel codigo de produccion. A traves de esta tecnica ydel uso de framework de testing el desarrollador pue-de identificar defectos en el diseno. Este trabajo haceuso de un framework de testing hardware, RC-Unity,desarrollado previamente en [4].

Por lo general, la mayorıa de disenos, tanto softwa-re como hardware, presentan dependencias con otrasentidades, lo que dificulta el proceso de test del di-seno bajo prueba. Esta dificultad viene dada debidoa que esas entidades de terceros no deben ser utiliza-das en entorno de verificacion con el fin de facilitar elproceso de verificacion sin necesidad de construir to-do el sistema, ya que es muy posible que esa entidadde terceros dependa a su vez de otra convirtiendola verificacion de un modulo en la construccion delsistema completo, algo que no es deseable. Por lotanto, lo deseable es instanciar lo mınimo posible delsistema final, y para conseguir este objetivo se puedehacer uso de los dobles de prueba.

Un doble de prueba es una entidad capaz de si-mular la interfaz que un determinado componenteofrece a otros componentes, pero que realmente noimplementa la funcionalidad del tercero, es decir, undoble imita el comportamiento del tercero haciendocreer al DUT que esta interactuando con la entidaddel tercero. Ademas, el doble tiene una serie de uti-lidades que permiten comprobar aquello que utilizoel DUT cuando invoco al tercero. Existen diferentestipos de dobles de pruebas, los cuales son clasificadossegun su comportamiento [7] [8]:

Stub. Reemplaza un objeto real por uno es-pecıfico para alimentar al DUT mediante unosvalores predefinidos, es decir retorna los valo-res configurados por el test cuando es invocado.Normalmente no responde a nada fuera de loprogramado.Fake. Reemplaza un componente del que depen-de el DUT con una implementacion mucho masligera, pero funcionalmente equivalente. Por logeneral son implementados de tal forma que nolos hacen no aptos para el codigo final.Mock. Sustituye un objeto del que depende elDUT por un objeto especıfico que verifica siel DUT lo esta utilizando correctamente. Estan

programados con una serie de expectativas quedeberıan cumplirse durante la ejecucion de laprueba. Si no se cumplen esas expectativas laprueba debera fallar.Spy. Como su propio nombre indica, capturalas llamadas realizadas por el DUT para su pos-terior verificacion. Esa verificacion se comprue-ba mediante aserciones para verificar que ciertasllamadas se realizaron. A diferencia del mock, nose comprueba la secuencialidad de las llamadasincluso pueden existir mas llamadas de las espe-radas, se podrıa decir que el spy es mas benevo-lente.

Entre los diferentes tipos de dobles de prueba, elmas interesante para el dominio hardware es el tipomock debido a su comportamiento, ya que este ti-po permite inspeccionar las invocaciones realizadaspor el DUT, proporcionando la informacion necesa-ria para conocer si la comunicacion con entidades deterceros es correcta, aspecto que el resto de doblesde prueba no permite.

III. RC-Mock framework: Dobles de pruebahardware

Para comprender la propuesta realizada en tornoa los dobles de prueba hardware es necesario exponerpreviamente nuestra vision de componente hardwarey como pueden ser modelados mediante herramientasHLS.

A. Encapsulado del hardware con HLS

Desde el punto de vista del progreso del disenoelectronico, el uso de lenguajes de programacion dealto nivel junto con las herramientas HLS abre ungran abanico de posibilidades permitiendo adoptartecnicas o metodologıas ampliamente aceptadas enla industria. Una de estas tecnicas es el ParadigmaOrientado a Objetos (POO), la cual aporta abstrac-cion, encapsulado, modularidad, robustez entre otrosa los sistemas desarrollados.

Desde el punto de vista del POO, un componen-te hardware puede modelarse como un conjunto defunciones, a ello le denominamos objeto hardware,por el alto grado de similitud con respecto a los ob-jetos software. La diferencia radica en la necesidadde definir un unico punto de entrada en el caso deldiseno electronico digital. Por otro lado, si el moduloque se esta desarrollando ofrece varias operacionescada una de esas operaciones sera definida en unafuncion distinta y debera garantizarse su acceso porun tercero.

La solucion propuesta consiste en definir una fun-cion top que encapsula el codigo del componente jun-to con un modulo denominado facade capaz de redi-rigir la entrada de datos a la funcion correspondiente.Mientras que la salida de cada una de las funcionesque componen el modulo es redirigida a un compo-nente denominado collector encargado de enviar elresultado. Por lo tanto, los modulos facade y collec-tor seran los encargados de establecer el camino porel que deben fluir los datos con el objetivo de esta-

Fig. 2: Objeto hardware (AES)

blecer un unico punto de entrada y salida al objetohardware. De esta forma, el objeto hardware puederecibir los datos de forma serializada y enviarlos dela misma forma (ver Figura 2).

Sin embargo, en este punto no hay forma de cono-cer que funcion debe ser ejecutada cuando los datosson recibidos por el componente. La solucion se basaen incluir un direccionamiento logico que se enviara atraves del canal de datos como si de una cabecera deun mensaje de red se tratase. Esta cabecera incluirados palabras de 16-bits que representan a un identi-ficador unico y al tamano de datos enviados expresa-do en palabras de 32-bits, que a su vez correspondaal ancho del canal de entrada del objeto hardware.Ademas, cada una de las funciones del objeto hard-ware tendra asignado de antemano un identificadorunico. Por consiguiente, el mensaje recibido por elobjeto hardware sera atendido por el modulo facadeque extraera los 32-bits correspondientes a la cabe-cera para determinar la funcion que debe ser ejecu-tada, a la vez dispondra de la cantidad de palabrasde 32-bits que debe transferir a dicha funcion. Encaso de recibir un identificador no conocido, el obje-to hardware rechazara el mensaje completamente, esdecir leera tantas palabras de 32-bits como indiqueel campo tamano de la cabecera.

La Figura 2 muestra la estructura interna del ob-jeto hardware correspondiente al algoritmo AES de128 bits cuya funcionalidad queda definida por losmetodos encrypt y decrypt, correspondientes a lasoperaciones de cifrar y descifrar, respectivamente. Lainterfaz del objeto hardware consta de dos canalescomunicacion, uno para los datos de entrada y otropara los datos de salida. Las senales de estos ca-nales corresponden a los de una FIFO cuyo anchode palabra es 32-bits. El funcionamiento del objetoAES se basa en tres sencillos pasos. En primer lugarse debe identificar la funcion a ejecutar (encrypt odecrypt), para ello el modulo facade obtiene unapalabra de 32-bits del canal de entrada (cabecera dedatos). En este instante se conoce que funcion debeser llamada y la cantidad de palabras de 32-bits quese deben leer del canal de entrada y enviar al moduloen cuestion que implementa la operacion solicitada.Previamente a ese envıo el modulo facade realizaraun casting hardware para adaptar los datos serializa-dos recibidos por el canal de entrada a la entrada delmodulo en cuestion. Una vez que el resultado se en-

cuentra disponible, el collector construira el mensajede retorno incluyendo los propios datos del resultadojunto con una pequena cabecera de 32-bits al ini-cio del mensaje, que consta del identificador de lafuncion y de la cantidad de palabras de 32-bits re-tornadas. Como se ha comentado, los datos enviadosal modulo solicitado deben ser serializados en pala-bras del mismo tamano que el canal de entrada, quecorresponde a 32-bits. En los casos que la cantidadde datos enviados hacia o desde el modulo no com-pleten palabras de 32-bits, se introducira el paddingnecesario para corregir el tamano de datos recibidoo enviado.

Como se ha comentado anteriormente, la interfazdel objeto hardware se basa en senales FIFO, que esel uso mas comun a la hora de disenar aceleradoreshardware mediante herramientas HLS. Esta interfazpuede ser adaptada a un bus estandar como es el busAXI de AMBA. Para ello, se debe disenar un driverde comunicaciones con la funcionalidad suficiente pa-ra interpretar el protocolo de bus y traducirlo a loscanales de comunicacion propuestos (doble interfazbasada en FIFO).

B. RC-Mock objects

RC-Mock framework sigue el mismo enfoque queotros frameworks: ofrecer una funcionalidad extrapara expresar con que frecuencia, con que argumen-tos y en que momento fue invocada una operacion ometodo mockeado, incluso retornar respuestas a esasllamadas con informacion almacenada previamente,es decir el objetivo es imitar una parte de la fun-cionalidad. Todo el codigo debe ser generado antesdel proceso de sıntesis, debido a que a los componen-tes de hardware no ofrece manipulacion de codigo entiempo de ejecucion, pero su configuracion si es po-sible realizarla posteriormente. Los dobles de pruebahardware se generan a partir de los ficheros de cabe-cera que contienen los metodos a mockear. El procesopara generar la funcionalidad del mock se realiza endos pasos:

El parser lee los archivos fuente del objeto amockear y construye el arbol de sintaxis (AST).Este proceso se realiza mediante Clang, que setrata de un front-end que utiliza LLVM comoback-end [9].A partir del AST se construye el objeto o funcionmockeada haciendo uso de una serie de planti-llas predefinidas mediante Ctemplate que es unsencillo pero potente lenguaje de plantillas paraC++ desarrollado por Google.

El resultado es un nuevo fichero de cabecera y ar-chivos fuente con codigo ANSI C sintetizable quecontiene la funcionalidad extra para configurar eldoble de prueba y para posteriormente interrogarque sucedio durante la ejecucion de un test (fun-ciones mock), tambien incluye la funcionalidad ne-cesaria para imitar los metodos reales que han si-do mockeados. Todo ello siguiendo la filosofıa deobjetos hardware presentada en la seccion anterior

#ifndef RD_MEM_MOCK#define RD_MEM_MOCK

#include <hls_stream.h>

typedef unsigned int tbus;

struct struct_readMem_PARAM{

unsigned int addr;};typedef struct_readMem_PARAM treadMem_PARAM;

struct struct_readMem_FAIL{

unsigned int _callCount;unsigned int _time;treadMem_PARAM _actual;treadMem_PARAM _expect;

};typedef struct_treadMem_FAIL treadMem_FAIL;

unsigned int readMem(unsigned int addr);void readMem_CallCount(hls::stream<tbus> &dout,

unsigned int &readMem_callCount);void readMem_FailureCount(hls::stream<tbus> &dout,

unsigned int &readMem_failureCount);void readMem_callTimes(hls::stream<tbus> &dout,

unsigned int &readMem_callTime);void readMem_Expect(hls::stream<tbus> &dout,

hls::stream<treadMem_PARAM> &readMem_expect);void readMem_failures(hls::stream<tbus> &dout,

hls::stream<treadMem_FAIL> &readMem_failures);

#endif

Fig. 3: Fichero de cabecera de la funcion mockeadareadMem

(ver Seccion III-A). La Figura 3 muestra el fiche-ro de cabecera obtenido a partir de la signaturaunsigned int readMem(unsigned int addr), queabstrae una operacion de lectura en memoria.

En primer lugar, el generador define dos estructu-ras para cada metodo mockeado; La primera estruc-tura contiene los parametros del metodo especıfico,en el ejemplo struct readMem PARAM esta forma-do por la direccion de memoria a leer; la segundaestructura tiene como objetivo definir la informacionalmacenada en caso de encontrar un error, es decirsi los datos de la configuracion del mock no corres-ponden con los datos recibidos por el diseno bajoprueba, en el ejemplo se comprobaran si la direccionde lectura es la esperada. Finalmente, para gestionarla informacion adicional, el generador define variasfunciones mock que responden a las peticiones rea-lizadas por las pruebas unitarias, proporcionando lainformacion almacenada en el doble de prueba. Porejemplo, el metodo readMem CallCount devuelve elnumero de veces que fue invocada la funcion moc-keada readMem. Por lo tanto, el doble de prueba dis-pondra de un conjunto de variables internas donde sealmacenara la informacion de lo que esta sucediendo,ası como de la configuracion establecida por el testantes de estimular el diseno bajo prueba. Las varia-bles con las que trabaja el doble de prueba son lassiguientes:

callCount Contador para el numero de llamadasrealizadas.failCount Contador para el numero de fallos de-tectados.

return values FIFO que contiene los valores deretorno del metodo mockeado.expected values FIFO que contiene los valoresesperados por el metodo mockeado.timestamp FIFO que contiene la marca de tiem-po en el que fue invocado el metodo mockeado.failures FIFO que contiene una traza de los fa-llos detectados.

Las funciones mock que contiene el doble de prue-ba dependera del tipo de funcion mockeada. La Ta-bla I muestra las posibles combinaciones dependien-do del metodo a mockear. Estas funciones permitiranacceder a las variables internas que componen el do-ble de prueba, bien para rescatar informacion de ellaso bien para el caso de las variables return values yexpected values almacenar los valores de retorno yesperados, respectivamente.

void func return(PARAM). Esta funcion al-macena los valores de retorno en la variablereturn values. Cuando la funcion mockeadaintenta leer datos de esta variable y no contieneninguno, se repetira el valor del ultimo enviado.void func expect(PARAM). Esta funcion al-macena los valores esperados en la variableexpected values. Su principal funcion es do-tar a la funcion mockeada los valores esperadospara posteriormente comprobar su similitud conel valor(es) recibido(s) como parametro(s).int func callCount(). Esta funcion retorna elnumero actual de veces que fue llamada la fun-cion mockeada, es decir, devuelve el valor de lavariable callCount.int func failCount(). Esta funcion devuelve elnumero de fallos encontrados, es decir, devuelveel valor de la variable failCount, que coincide conla cantidad de items almacenados en la variablefailures.int func timestamp(). Esta funcion devuelveuna marca de tiempo correspondiente a las lla-madas realizadas por el DUT a la funcion moc-keada. Para obtener todas las marcas de tiempose deberan realizar tantas llamadas a este meto-do como indique la variable callCount. La in-formacion de tiempos es obtenida en el mismoorden que la funcion mockeada fue invocada.FAIL func failures(). Esta funcion retorna lastrazas de errores encontrados por la funcionmockeada. Para obtener todas las trazas se de-beran realizar tantas llamadas a este metodo co-mo indique la variable failCount. La informacionde los errores es rescatada en el mismo orden enel que fueron detectados.

Desde el punto de vista estructural la funcion moc-keada del ejemplo quedarıa representada en la Figu-ra 4, la cual representa su diagrama de bloques. Es-te diagrama de bloques contiene las funciones mocklistadas anteriormente y las variables responsablesde almacenar la informacion necesaria para imitar lafuncionalidad del tercero (return y expect), junto conlas variables que almacenan informacion del compor-

Fig. 4: Diagrama de bloques de readMem

unsigned int readMem(unsigned int addr){

treadMem_FAIL auxFail;unsigned int _return;unsigned int _expect_addr;int _diff;unsigned int _time;

_expect_addr = readMem_expect.read().addr;_time = timeClock.read();_diff = abs(addr - _expect_addr);

if(_diff > DELTA){auxFail._callCount = readMem_callCount;auxFail._param.addr = addr;auxFail._expect.addr = _expect_addr;auxFail._time = _time;readMem_failures.write(auxFail);readMem_failureCount += 1;

}readMem_timestamp.write(_time);_return = readMem_return.read()._return;readMem_callCount += 1;

return _return;}

Fig. 5: Cuerpo de la funcion mockeada readMem

tamiento observado tras la ejecucion de un test.

En la parte superior de la figura se situa la funcionmockeada, readMem, que desde el punto de vista delcomportamiento, la funcion comienza a leer el valoresperado y la marca de tiempo en el que es invo-cada dicha funcion por el diseno bajo prueba. A lavez se compara el valor actual con el esperado, cuyoresultado determinara si debe almacenarse la trazade error o no. Si los valores no coinciden, la fun-cion mockeada escribira la informacion concernienteal fallo en la variable failures. Esta variable permiteenviar una traza del fallo encontrado al test, indi-cando: la invocacion que detecto el fallo, la marcade tiempo en que sucedio la invocacion y los valo-res reales y esperados. A continuacion, se aumenta elcontador de fallos (failureCount). Por ultimo, inde-pendientemente si se detecto un fallo o no, la funcionmockeada almacena la marca de tiempo leıda en elprimer paso, lee los valores de retorno (siempre quela funcion mockeada deba devolver algo) y aumen-ta la variable callCount. Finalmente, se devuelve elvalor o los valores de retorno (ver Figura 5).

TABLA I: Relacion entre funciones mockeadas y propiedades

Propiedades MockFunc. mockeada return expect callCount failureCount timestamp failures

void foo(void) - - X - X -void foo(args) - X X X X Xret foo(args) X X X X X X

IV. Plataforma de verificacion hardware

Uno de los objetivos en los que se centra este tra-bajo es proporcionar una plataforma de verificacionhardware para probar los modulos generados por he-rramientas HLS y mejorar el analisis que proporcio-nan. Nuestra plataforma de verificacion se basa enuna plataforma SoC que integra una FPGA y unprocesador embebido en el mismo dispositivo. Ennuestro caso, utilizamos la plataforma de prototipa-do Zedboard de Xilinx.

La eleccion de esta plataforma se debe a la fa-cilidades que proporciona de comunicacion entre elprocesador embebido y la parte logica. Ademas, laplataforma Zedboard se puede conectar a una reda traves de Ethernet con el objetivo de comunicar-se con el equipo donde se han desarrollado moduloshardware. El framework de pruebas utilizado, RC-Unity, tambien es remoto, por lo que la FPGA puededesempenar el papel de servicio de testing remoto.

A la derecha de la Figura 6 se muestra el diagramade bloques de la parte logica de la plataforma deverificacion hardware. El modulo a verificar junto conlos dobles de prueba estan programados en este ladoy su comunicacion con el procesador embebido serealiza a traves de dos canales FIFO conectados auna interfaz AXI.

La parte logica esta dividida en dos partes, unaestatica que contiene aquellos componentes que nocambian independientemente de la logica que se ve-rifique, mientras que esta parte, el DUT, se despliegaen un area dinamica reconfigurable. Dos de las ven-tajas del uso de la reconfiguracion dinamica parcial(Dynamic Partial Reconfiguration, DPR) es la reduc-cion del tiempo de sıntesis [10] y la posibilidad deinsertar dinamicamente nuevas funcionalidades sinnecesidad de redisenar todo el sistema o cambiar elsistema desarrollado a un dispositivo mas grande.Ademas, es posible adaptar una FPGA a diferen-tes escenarios, simplemente modificando la funciona-lidad que contienen las zonas dinamicas. EL entonode verificacion propuesto se basa en la caracterısticaDPR que permite reutilizar el entorno en diferentesproyectos.

El componente zipFactory es el encargado de pro-gramar (desplegar fısicamente) un bitstream parcialen el area dinamica disponible de nuestra platafor-ma de verificacion sin la intervencion del procesa-dor embebido. Para ello, recupera los datos del bits-tream parcial, que previamente estara almacenadoen la DDR. Este componente es capaz de reconocerla palabra de desincronizacion que contienen los bits-treams para dejar de leer en ese mismo instante. Losdatos recuperados se almacenan en un pequeno buf-

fer interno, asegurando la disponibilidad de datos aenviar al ICAP para el despliegue fısico. El ancho debanda utilizado en el ICAP es de 32-bits, que coin-cide con el ancho del buffer interno. En el momentoque se envıa la palabra de desincronizacion, el proce-so de reconfiguracion finaliza, aunque algunos NOPsson enviados al ICAP.

El componente Hardware Manager realiza un con-junto de tareas hardware referentes a la verificacion(cada una de estas tareas son controladas desde eltest) que no serıan factibles realizar desde el entornode pruebas de software. Estas tareas van desde rese-tear la zona dinamica a configurar la frecuencia a laque trabajara la zona dinamica, es decir el DUT.

A la izquierda de la Figura 6 se muestra la partedel procesador embebido, junto con la comunicacioncon el equipo del desarrollador. El procesador em-bebido se trata de un procesador ARM que ejecutaun sistema operativo basado en Ubuntu (distribu-cion Linaro). Para utilizar los componentes internosde la plataforma de verificacion, se han desplegadosobre este sistema operativo tres servicios basados enmiddleware de comunicaciones ZeroC Ice. Por ejem-plo, cuando se quiere desplegar un nuevo bitstreamparcial, se debe enviar los datos que componen estefichero a la DDR de la FPGA, para ello se utilizarael servicio transfer que permite copiar datos a par-tir de una direccion de memoria. En ese instante sepuede utilizar el servicio dpr para desplegar la nuevafuncionalidad en la area dinamica. Por lo tanto, es-te trabajo proporciona un mecanismo transparenteque permite compartir la plataforma de verificacionhardware, aumentando su disponibilidad y accesibi-lidad. Finalmente, para inyectar estımulos y rescatarinformacion de los dobles de prueba se puede haceruso del servicio GCommand que traduce los mensa-jes enviados por la red en mensajes AXI cuya direc-cion hardware coincide con la del DUT.

Como puede observarse, gracias a estos tres servi-cios es posible hacer uso de la plataforma de verifi-cacion hardware de forma remota, haciendo uso delos adaptadores de estos tres servicios que permitenserializar los datos en mensajes ZeroC Ice. Estos ser-vicios se muestran como funciones desde el punto devista del test.

V. Caso de estudio

Nuestra propuesta ha sido desarrollada bajo unentorno GNU/Linux e implementada en la platafor-ma Zedboard de Xilinx. Por defecto, la plataformafunciona a 100 MHz, pero el area dinamica y otroscomponentes pueden modificar esta velocidad de re-loj en tiempo de ejecucion de acuerdo a las necesida-

Fig. 6: Plataforma de verificacion hardware

Fig. 7: Factor de normalizacion l2-norm

des del proyecto. Como caso de estudio de este tra-bajo hemos seleccionado un algoritmo de descripcionde caracterısticas basado en gradientes (Histogram ofOriented Gradients, HOG). El HOG es un descriptorde caracterısticas utilizado en vision por computadory en el procesamiento de imagenes para la deteccionde objetos, especialmente para la deteccion huma-na. La implementacion del algoritmo se divide en di-ferentes pasos: calculo de gradientes, normalizacionvectorial, entre otros. En este caso de estudio, la eta-pa elegida corresponde con la normalizacion vectorialcon el factor de normalizacion l2-norm [11]. La solu-cion a esta etapa ha sido desarrollada en el lenguajede programacion C utilizando la herramienta VivadoHLS en su version 2016.4 [12].

La Figura 7 muestra una posible solucion para laetapa elegida como caso de estudio con el algoritmol2-norm. Para el caso de estudio presente, el factorde normalizacion toma como entrada un ventana depıxeles de 4x4 (16 pıxeles) y es dividido en tres pasosmas pequenos (A, B y C) antes que el resultado seadevuelto a traves de histOUT, el cual es calculadopor el sub-bloque C. Mientras tanto, los sub-bloquesA y B calcula la suma de los cuadrados de los com-ponentes del bloque de entrada y el factor de escalarespectivamente (ver lado izquierdo de la Figura 7).Siguiendo la filosofıa de los objetos hardware presen-tada en este trabajo, este modulo contendra un unicometodo que anida otros tres metodos correspondien-tes a los sub-bloques, que se encuentran interconec-tados entre sı. Por lo tanto, desde el punto de vista deun usuario que desee utilizar este bloque solo podrahacer uso de la unica funcion que engloba al resto,

pero ¿que sucederıa si el sub-bloque B dependiera deuna tercera entidad? De acuerdo a la propuesta pre-sentada en este trabajo, el sub-bloque B (la funcionque implementa B) debera ser mockeada con el obje-tivo que los sub-bloques A y C puedan ser verificadossin la necesidad de instanciar la dependencia de B.

Por lo tanto, el sub-bloque B quedara definido co-mo un doble de prueba que permitira inspeccionarla comunicacion entre los sub-bloques A y B, mien-tras que el sub-bloque C sera estimulado por el doblede prueba y por lo tanto se podra introducir aque-llos estımulos que se deseen independientemente delresultado aportado por el sub-bloque A, acotandoposibles errores producidos por el sub-bloque A, esdecir si A devuelve un resultado erroneo no afectaraa C, ya que el doble de prueba que imita al sub-bloque B permite detectar fallos en las invocacionesrealizadas por A y producir estımulos correctos parael sub-bloque C.

A. Tests con dobles de prueba

Una vez definido el doble de prueba hardware que-da por describir como se utilizara dicho doble y susfunciones mock para extraer la informacion almace-nada tras estimular el diseno bajo prueba. Para ello,hacemos uso de una representacion virtual del doblede prueba y del diseno bajo test. Desde el punto devista del test estas representaciones virtuales pue-den verse como llamadas a funciones que aportantransparencia de localizacion y comunicacion con laimplementacion final. En la Figura 8 se muestra elcaso de prueba para el factor de normalizacion l2-norm. En primer lugar, antes de utilizar la macroRCUNITY SETUP() y estimular el diseno, se debe con-figurar el doble de prueba (sub-bloque B o funcionscale). Para estas tareas se hara uso de las funcionesmock scale expect y scale return que permiten con-figurar los valores esperados en una llamada y losvalores de retorno, respectivamente. Posteriormente,el diseno bajo prueba es estimulado para comprobarsu comportamiento sin una implementacion real delsub-bloque B, como se indico en su configuracion seconoce de antemano que el sub-bloque A producirael resultado 1240.0 que sera utilizado como parame-tro de entrada para el sub-bloque B, mientras queel sub-bloque B inyectara en el sub-bloque C el va-lor 0.027164. Se debe recordar que estos valores solo

#include "rc-unity.h"#include "scale.h"

voidtest_caseA(){#ifdef TIMING

RCUNITY_SKIP_INPUT(18);RCUNITY_SKIP_OUTPUT(1);

#endif

scale_return(0.027164);scale_expect(1240.0);

#ifdef TIMINGRCUNITY_SETUP();

#endif

RCUNITY_RESET();float out[HIST_SIZE];l2norm(input, out);

for(int i = 0; i != HIST_SIZE; i++)TEST_ASSERT_EQUAL_FLOAT(ref[i], out[i]);

printf("Calls %d\n",scale_callCount());printf("Failures %d\n",scale_failureCount());scale_print_failures();

}

Fig. 8: Test para el algoritmo l2-norm

son validos para este caso de prueba, para otro casose debe volver a configurar el doble de prueba des-de el test, el componente hardware referente al doblede prueba no variara. Cuando el diseno bajo pruebafinaliza su ejecucion, se comprobara el resultado pro-ducido por este. Ademas, se podra rescatar informa-cion del doble de prueba para conocer el comporta-miento que tuvo el diseno, permitiendo conocer si elsub-bloque A devolvio un resultado correcto, las ve-ces que fue llamado la funcion mockeada y los erroresque se detectaron durante la ejecucion de la prueba,junto con una traza de los errores detectados.

VI. Conclusion y Trabajo Futuro

RC-Mock es un framework para la generacion democks hardware que aprovecha los avances realiza-dos en el diseno electronico con herramientas HLS,permitiendo la capacidad de crear objetos hardwarey aplicar tecnicas de testing ampliamente aceptadasen el mundo industrial. RC-Mock se centra en la ulti-ma etapa del desarrollo hardware (verificacion sobreel dispositivo fısico) y complementa el trabajo rea-lizado previamente con el framework hardware RC-Unity. Los dobles de prueba hardware ofrecen unasolucion clara para sustituir las dependencias de ter-ceros de forma transparente, permitiendo un anali-sis post-estimulacion. Este analisis. en cierta medi-da, permite realizar una introspeccion hardware deun diseno, ya que es posible sustituir parte del disenopor un doble de prueba y posteriormente analizar losvalores con los que se le estimulo.

El trabajo futuro se centra en aserciones hardwaresintetizables, con el fin de mejorar las capacidadesde verificacion en tiempo real de nuestra platafor-ma y aumentar la visibilidad de las senales internas,sin perturbar el rendimiento del diseno original o ha-ciendolo mınimamente.

Agradecimientos

Este trabajo ha sido financiado por el Mi-nisterio de Economıa y Competitividad del Go-bierno de Espana bajo el proyecto PLATINO

(TEC2017-86722-C4-4-R) y por la Consejerıa deEducacion, Cultura y Deportes de la Junta de Co-munidades de Castilla-La Mancha bajo el proyectoSimbIoT (SBPLY-17-180501-000334).

Referencias

[1] A. Canis, J. Choi, B. Fort, R. Lian, Q. Huang, N. Ca-lagar, M. Gort, J. J. Qin, M. Aldham, T. Czajkowski,S. Brown, and J. Anderson, “From software to acce-lerators with LegUp high-level synthesis,” in 2013 In-ternational Conference on Compilers, Architecture andSynthesis for Embedded Systems (CASES), Sept 2013,pp. 1–9.

[2] J. Cong, B. Liu, S. Neuendorffer, J. Noguera, K. Vis-sers, and Z. Zhang, “High-Level Synthesis for FPGAs:From Prototyping to Deployment,” IEEE Transactionson Computer-Aided Design of Integrated Circuits andSystems, vol. 30, no. 4, pp. 473–491, April 2011.

[3] W. Chen, S. Ray, J. Bhadra, M. Abadir, and L. C. Wang,“Challenges and Trends in Modern SoC Design Verifica-tion,” IEEE Design Test, vol. 34, no. 5, pp. 7–22, Oct2017.

[4] Julian Caba, Joao M. P. Cardoso, Fernando Rincon, Ju-lio Dondo, and Juan Carlos Lopez, “Rapid prototypingand verification of hardware modules generated usinghls,” in Applied Reconfigurable Computing. Architec-tures, Tools, and Applications, Nikolaos Voros, MichaelHuebner, Georgios Keramidas, Diana Goehringer, Chris-tos Antonopoulos, and Pedro C. Diniz, Eds., Cham, 2018,pp. 446–458, Springer International Publishing.

[5] Lingkan Gong and Oliver Diessel, Verification Challen-ges, chapter 2, pp. 15–40, Springer International Publis-hing, Cham, 2015.

[6] Robert Cecil Martin, Agile Software Development: Prin-ciples, Patterns, and Practices, Prentice Hall PTR, Up-per Saddle River, NJ, USA, 2003.

[7] F. Moya, C. Gonzalez, D. Villa, S. Perez, M.A. Redondo,C. Mora, F.J. Villanueva, and M. Garcıa, Desarrollo deVideojuegos: Tecnicas Avanzadas, Bubok, 2011.

[8] G. Meszaros, “Test double patterns,” http://xunitpatterns.com, 2008.

[9] Apple, Inc., “clang: a C language family frontend forLLVM,” http://clang.llvm.org/ ; accessed 16-Feb-2018.

[10] W. Lie and W. Feng-yan, “Dynamic partial reconfigura-tion in fpgas,” in 2009 Third International Symposiumon Intelligent Information Technology Application, Nov2009, vol. 2, pp. 445–448.

[11] N. Dalal and B. Triggs, “Histograms of oriented gradientsfor human detection,” in 2005 IEEE Computer SocietyConference on Computer Vision and Pattern Recogni-tion (CVPR’05), June 2005, vol. 1, pp. 886–893 vol. 1.

[12] Xilinx, “Vivado Design Suite User Guide: High-LevelSynthesis (UG902),” Tech. Rep., Xilinx Inc., 2017.