{"id":185,"date":"2020-06-04T10:37:49","date_gmt":"2020-06-04T10:37:49","guid":{"rendered":"http:\/\/dsd.webs.upv.es\/?page_id=185"},"modified":"2020-09-24T10:03:44","modified_gmt":"2020-09-24T10:03:44","slug":"que-son-las-aserciones","status":"publish","type":"page","link":"https:\/\/dsd.webs.upv.es\/?page_id=185","title":{"rendered":"Aserciones: cuestiones b\u00e1sicas"},"content":{"rendered":"\n

\u00bfQu\u00e9 son las aserciones?<\/h2>\n\n\n\n
\n

Su prop\u00f3sito es asegurar la consistencia entre lo que el dise\u00f1ador intenta dise\u00f1ar y lo que la implementaci\u00f3n realmente hace.<\/p>\n\n\n\n

\u00abAssertion\u201d  es un estamento que describe el comportamiento deseado del dise\u00f1o. Esa pieza de c\u00f3digo est\u00e1 en todo momento inspeccionando nuestras se\u00f1ales y la interrelaci\u00f3n entre ellas (autochequeo) y mientras ese comportamiento deseado se cumpla la aserci\u00f3n no dice nada. Pero si ese comportamiento deseado no se cumple entonces se dice que la aserci\u00f3n Falla<\/strong> y empieza a emitir informaci\u00f3n importante para el ingeniero que est\u00e1 dise\u00f1ando y verificando un bloque funcional.<\/p>\n<\/div><\/div>\n\n\n\n

Las claves de las \u201cassertions\u201d :<\/p>\n\n\n\n

1.<\/em> Detecci\u00f3n del Error detection<\/em><\/span><\/strong> :<\/span> <\/em>Si la aserci\u00f3n se viola (falla<\/strong>), el simulador lo detecta. <\/p>\n\n\n\n

2. <\/em>Aislamiento del Error<\/em><\/span><\/strong> :<\/span> <\/em>Las se\u00f1ales involucradas en esa violaci\u00f3n son identificadas por el simulador. <\/p>\n\n\n\n

3. <\/em>Notificaci\u00f3n del Error<\/em><\/span><\/strong> <\/span>: <\/em>La fuente del error es notificada al usuario.<\/p>\n\n\n\n

Tipos de notificaciones<\/h2>\n\n\n\n

Las notificaciones consisten en un mensaje y un grado de severidad del fallo de comportamiento detectado. Las notificaciones se realizan despu\u00e9s de la palabra reservada else<\/span> mediante las siguientes funciones predefinidas:<\/p>\n\n\n\n

<\/p>\n\n\n\n

  • $fatal(\u201c\u2026\u201d);<\/span> Se cierra la simulaci\u00f3n<\/strong>, no tiene ning\u00fan sentido continuar <\/li>
  • $error(\u201c\u2026\u201d);<\/span> Se suele para la simulaci\u00f3n<\/strong> \u2013 se puede continuar si el usuario lo desea <\/li>
  • $warning(\u201c\u2026\u201d);<\/span> Parecido al error; pero se puede inhabilitar <\/li>
  • $info(\u201c\u2026\u201d);<\/span> Se muestra un mensaje por consola sin parar la simulaci\u00f3n. C\u00f3mo bien dice la palabra, puede ser una informaci\u00f3n que necesitamos conocer sin que sea realmente un fallo<\/li><\/ul>\n\n\n\n

    \u00bfQui\u00e9n hace las aserciones?<\/h2>\n\n\n\n

    Para contestar esa pregunta debemos centrarnos en las aserciones concurrentes, que son sin duda el elemento fundamental en el que se basa la metodolog\u00eda ABV( Assertion Based Verification).<\/p>\n\n\n\n

    Las aserciones deber\u00edan ser escritas por los mismos ingenieros que se han dedicado a escribir el RTL del dise\u00f1o. De hecho el lugar natural para esas aserciones concurrentes es en el interior del m\u00f3dulo que yo quiero autochequear. Por supuesto esto hace que dicho c\u00f3digo sea analizado tanto por las herramientas de s\u00edntesis (por ejemplo el sintetizador incluido en el flujo de Quartus) como por las herramientas de verificaci\u00f3n (un simulador HDL como Questasim). <\/p>\n\n\n\n

    Afortunadamente todo lo que escribamos en systemVerilog perteneciente al mundo de las aserciones (SVA) es ignorado por los compiladores de los sintetizadores y no intenta implementarlo con lo cual no generar\u00e1 errores. <\/p>\n\n\n\n

    Sin embargo los simuladores HDL no solo analizan este c\u00f3digo (para detectar errores sint\u00e1cticos) sino que cuando se ejecutan recopilan la actividad de estas monitorizaciones continuas ejercidas por estas aserciones y las representan con detalle en diferentes ventanas e informes espec\u00edficamente desarrollados para este tipo de verificaci\u00f3n.<\/p>\n\n\n\n

    \u00bfQu\u00e9 tengo que monitorizar?<\/h2>\n\n\n\n

    Cuando tengo un dise\u00f1o tengo unas especificaciones de c\u00f3mo debe de comportarse un circuito en sus salidas cuando recibe unas entradas determinadas. Por supuesto en la mayor\u00eda de los sistemas que tenemos que dise\u00f1ar ese comportamiento de las salidas no solo depende de las entradas sino de un hist\u00f3rico del sistema que viene representado por el estado del control path. <\/p>\n\n\n\n

    Supongamos un peque\u00f1o sistema con su control-path y su data path formado por diferentes subsistemas como contadores, registros, circuitos aritm\u00e9ticos , registros de desplazamiento , memorias, etc.<\/p>\n\n\n\n

    Voy a listar que se podr\u00eda chequear:<\/p>\n\n\n\n

    • Los modos de funcionamiento de los subsistemas: por ejemplo se que en un estado debe de incrementarse un contador y compruebo que el contador realmente se incrementa en ese estado. Digamos que autochequeo que los mandatos del control path efectivamente surten efecto en ese elemento del data path en concreto.<\/li>
    • El modo de funcionamiento general: por ejemplo s\u00e9 que en un estado de un microprocesador voy a sumar una variable que se va a direccionar dependiendo de un valor almacenado en memoria RAM y le voy a sumar un valor inmediato expresado en la propia instrucci\u00f3n y lo voy a almacenar en el banco de registros. Pues al final de esa instrucci\u00f3n compruebo si efectivamente se ha realizado ese comportamiento.<\/li>
    • Puedo comprobar las salidas de control si son congruentes con el estado del sistema.Por ejemplo tengo una fifo que he llenado y s\u00e9 que el flag de fifo llena debe de ponerse a cero. Pues compruebo si hace realmente eso.<\/li>
    • Tambi\u00e9n puedo comprobar que los est\u00edmulos recibidos por el sistema (Entradas) son acordes a las especificaciones y que no someto el DUV a entradas no legales o incluso prohibidas. Un ejemplo ser\u00eda en el caso de la FIFO comprobar que nunca escribo de la FIFO llena (sin lectura simult\u00e1nea) o nunca leo de una FIFO vac\u00eda (sin escritura simult\u00e1nea)<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"

      \u00bfQu\u00e9 son las aserciones? Su prop\u00f3sito es asegurar la consistencia entre lo que el dise\u00f1ador intenta dise\u00f1ar y lo que la implementaci\u00f3n realmente hace. \u00abAssertion\u201d  es un estamento que describe el comportamiento deseado del dise\u00f1o. Esa pieza de c\u00f3digo est\u00e1 en todo momento inspeccionando nuestras se\u00f1ales y la interrelaci\u00f3n entre ellas (autochequeo) y mientras ese comportamiento deseado se cumpla la aserci\u00f3n no dice nada. Pero si ese comportamiento deseado no se cumple entonces se dice que la aserci\u00f3n Falla y empieza a emitir informaci\u00f3n importante para el ingeniero que est\u00e1 dise\u00f1ando y verificando un bloque funcional. Las claves de las \u201cassertions\u201d : 1. Detecci\u00f3n del Error detection : Si la aserci\u00f3n se viola (falla), el simulador lo detecta. 2. Aislamiento del Error : Las se\u00f1ales involucradas en esa violaci\u00f3n son identificadas por el simulador. 3. Notificaci\u00f3n del Error : La fuente del error es notificada al usuario. Tipos de notificaciones Las notificaciones consisten en un mensaje y un grado de severidad del fallo de comportamiento detectado. Las notificaciones se realizan despu\u00e9s de la palabra reservada else mediante las siguientes funciones predefinidas: $fatal(\u201c\u2026\u201d); Se cierra la simulaci\u00f3n, no tiene ning\u00fan sentido continuar $error(\u201c\u2026\u201d); Se suele para la simulaci\u00f3n \u2013 se puede continuar si el usuario lo desea $warning(\u201c\u2026\u201d); Parecido al error; pero se puede inhabilitar $info(\u201c\u2026\u201d); Se muestra un mensaje por consola sin parar la simulaci\u00f3n. C\u00f3mo bien dice la palabra, puede ser una informaci\u00f3n que necesitamos conocer sin que sea realmente un fallo \u00bfQui\u00e9n hace las aserciones? Para contestar esa pregunta debemos centrarnos en las aserciones concurrentes, que son sin duda el elemento fundamental en el que se basa la metodolog\u00eda ABV( Assertion Based Verification). Las aserciones deber\u00edan ser escritas por los mismos ingenieros que se han dedicado a escribir el RTL del dise\u00f1o. De hecho el lugar natural para esas aserciones concurrentes es en el interior del m\u00f3dulo que yo quiero autochequear. Por supuesto esto hace que dicho c\u00f3digo sea analizado tanto por las herramientas de s\u00edntesis (por ejemplo el sintetizador incluido en el flujo de Quartus) como por las herramientas de verificaci\u00f3n (un simulador HDL como Questasim). Afortunadamente todo lo que escribamos en systemVerilog perteneciente al mundo de las aserciones (SVA) es ignorado por los compiladores de los sintetizadores y no intenta implementarlo con lo cual no generar\u00e1 errores. Sin embargo los simuladores HDL no solo analizan este c\u00f3digo (para detectar errores sint\u00e1cticos) sino que cuando se ejecutan recopilan la actividad de estas monitorizaciones continuas ejercidas por estas aserciones y las representan con detalle en diferentes ventanas e informes espec\u00edficamente desarrollados para este tipo de verificaci\u00f3n. \u00bfQu\u00e9 tengo que monitorizar? Cuando tengo un dise\u00f1o tengo unas especificaciones de c\u00f3mo debe de comportarse un circuito en sus salidas cuando recibe unas entradas determinadas. Por supuesto en la mayor\u00eda de los sistemas que tenemos que dise\u00f1ar ese comportamiento de las salidas no solo depende de las entradas sino de un hist\u00f3rico del sistema que viene representado por el estado del control path. Supongamos un peque\u00f1o sistema con su control-path y su data path formado por diferentes subsistemas como contadores, registros, circuitos aritm\u00e9ticos , registros de desplazamiento , memorias, etc. Voy a listar que se podr\u00eda chequear: Los modos de funcionamiento de los subsistemas: por ejemplo se que en un estado debe de incrementarse un contador y compruebo que el contador realmente se incrementa en ese estado. Digamos que autochequeo que los mandatos del control path efectivamente surten efecto en ese elemento del data path en concreto. El modo de funcionamiento general: por ejemplo s\u00e9 que en un estado de un microprocesador voy a sumar una variable que se va a direccionar dependiendo de un valor almacenado en memoria RAM y le voy a sumar un valor inmediato expresado en la propia instrucci\u00f3n y lo voy a almacenar en el banco de registros. Pues al final de esa instrucci\u00f3n compruebo si efectivamente se ha realizado ese comportamiento. Puedo comprobar las salidas de control si son congruentes con el estado del sistema.Por ejemplo tengo una fifo que he llenado y s\u00e9 que el flag de fifo llena debe de ponerse a cero. Pues compruebo si hace realmente eso. Tambi\u00e9n puedo comprobar que los est\u00edmulos recibidos por el sistema (Entradas) son acordes a las especificaciones y que no someto el DUV a entradas no legales o incluso prohibidas. Un ejemplo ser\u00eda en el caso de la FIFO comprobar que nunca escribo de la FIFO llena (sin lectura simult\u00e1nea) o nunca leo de una FIFO vac\u00eda (sin escritura simult\u00e1nea)<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":183,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_crdt_document":"","ub_ctt_via":"","footnotes":""},"class_list":["post-185","page","type-page","status-publish","hentry"],"featured_image_src":null,"_links":{"self":[{"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=\/wp\/v2\/pages\/185","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=185"}],"version-history":[{"count":15,"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=\/wp\/v2\/pages\/185\/revisions"}],"predecessor-version":[{"id":268,"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=\/wp\/v2\/pages\/185\/revisions\/268"}],"up":[{"embeddable":true,"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=\/wp\/v2\/pages\/183"}],"wp:attachment":[{"href":"https:\/\/dsd.webs.upv.es\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=185"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}