Logotipo de Zephyrnet

La búsqueda de errores: “¡La verificación es un problema de datos!” – Semiwiki

Fecha:

Análisis de datos de verificación

La verificación de hardware es un problema que requiere un uso intensivo o intensivo de datos. Los ingenieros de verificación reconocen esto y dedican gran parte de su tiempo a lidiar con conjuntos de datos grandes y complejos que surgen de los procesos de verificación.

En la opciónLos dilemas de la verificación de hardware”Exploramos los desafíos clave en torno a la verificación de sistemas y IP de hardware complejos. El “dilema de la integridad” lleva a los equipos de ingeniería a depender en gran medida de los datos y el análisis de datos, para hacer que los procesos incompletos sean mensurables y acotados y permitir que los equipos de desarrollo de productos tomen decisiones basadas en datos sobre la calidad de aprobación para los lanzamientos de productos.

De hecho, una de las muchas habilidades básicas de un buen ingeniero de verificación es el análisis de datos.

Los grandes ingenieros de verificación deben ser excelentes analistas de datos.

Los ingenieros manejan enormes volúmenes de datos: conjuntos de pruebas, resultados de pruebas, resultados de cobertura, datos de utilización y planificación de recursos, datos de control de versiones, análisis de exenciones, seguimiento de errores y defectos y optimización continua y mejora continua a través del análisis de tendencias y análisis de causas fundamentales.

Al hacerlo, los ingenieros de verificación utilizan muchas fuentes de datos diferentes para garantizar que los proyectos vayan por buen camino y avancen hacia los objetivos del proyecto, al tiempo que garantizan que haya información precisa disponible para respaldar las decisiones de aprobación en hitos clave de calidad que ocurren durante el ciclo de vida del desarrollo del producto.

Los datos de verificación también presentan una gran oportunidad para optimizar y agilizar los flujos de trabajo de verificación.

El retorno de la inversión del producto final entregado está determinado en gran medida por los costos de desarrollo, y está bien documentado que el 70% o más de estos costos son atribuibles a las actividades de verificación. Por lo tanto, se debe tener cuidado para garantizar que las actividades de verificación sean efectivas y eficientes y no derrochadoras.

Por supuesto, un grado saludable de paranoia es útil desde la perspectiva de un ingeniero de verificación, ya que existe una fuerte compulsión a ejecutar más y más ciclos de verificación porque un escape de error que llegue al cliente o usuario final puede ser extremadamente costoso, impactante y potencialmente dañino para la reputación. Ver "El costo de los errores” donde exploramos el equilibrio entre el “costo de encontrar errores” (los costos de verificación) versus el “costo de no encontrar errores” (los costos de impacto de las fugas de errores).

Perspectivas de los datos

El valor de los datos de verificación se materializa cuando arrojan información clave.

Piense en las ideas como preguntas.

Una idea podría ser una pregunta de alto nivel que un gerente de ingeniería le hace al equipo de ingeniería para comprender qué tan efectivo o eficiente es el proceso de desarrollo de productos. También podría ser una pregunta formulada por el equipo de liderazgo senior, el equipo de calidad o el equipo de ventas e ingresos.

Los conocimientos también pueden impulsar una estrategia de mejora continua habilitada por una comprensión de la eficacia y la eficiencia.

En algunos casos, las ideas pueden ser impredecibles o inesperadas. La curiosidad y un enfoque analítico para limpiar, comprender, explorar y validar los datos y revisar las vistas analíticas pueden revelar observaciones que no estaban disponibles anteriormente. Estos conocimientos inesperados presentan oportunidades para desafiar el status quo en ocasiones y repensar las prácticas establecidas. Sin embargo, se debe tener cuidado de cuestionar y validar los supuestos.

Tenga en cuenta que a veces es posible hacer que los análisis se ajusten a la narrativa y no al revés.

Es útil pensar en insights en el contexto de una pila de datos y valor, como se ilustra en la Figura 1: La pirámide inversa de Analytics.

Los conocimientos permiten la toma de decisiones basada en datos.

Los conocimientos son posibles gracias a un buen análisis de datos, que a su vez está habilitado por modelos de datos construidos a partir de las fuentes de datos cargadas en el lago de datos. El punto es descubrir primero qué decisiones basadas en datos requiere la empresa y dejar que esto impulse la captura de datos, las canalizaciones de datos y el análisis de datos, ¡no al revés!

Figura 1 y XNUMX

Figura 1 La pirámide inversa de Analytics

Los datos sin procesar en la base de la pirámide tienen poco valor a menos que sean limpios y precisos y se alimenten a través de un canal de datos que genere análisis poderosos que generen conocimientos de alto valor.

La anatomía de los datos y por qué debería importarnos...

Si seguimos las preocupaciones a nivel ejecutivo que impulsan la excelencia en la verificación hasta llegar a la realidad de la ingeniería de verificación (las actividades diarias), podemos describir mejor lo que sucede en cada etapa.

Desde el punto de vista del director financiero y de los directores ejecutivos, hay múltiples cuestiones de las que preocuparse, pero cuando se relaciona con el desarrollo de ingeniería de todos los productos importantes que generan ingresos de la empresa, todo se reduce a estos.

Figura 2 y XNUMX

Figura 2 Costo, Calidad y Entrega

Los clientes quieren los mismos resultados de su proveedor, lo que significa que el esfuerzo de verificación que usted realice debe ser efectivo y eficiente para generar soluciones rentables para ellos. Para lograr esto, sus procesos de diseño y verificación deben estar bien instrumentados para evitar el llamado síndrome de la "caja negra", por el cual los productos llegan sin una idea clara de qué tan bueno ha sido el esfuerzo de verificación para encontrar errores y tal vez sin un buen manejo. sobre los costos o los plazos del proyecto.

La excelencia depende de buenos datos y de una cultura de ingeniería que sepa cómo explotarlos.

Figura 3 Canalizaciones de datos, A continuación, se indica la importancia de los análisis para proporcionar información sobre el esfuerzo de verificación para evaluar la eficacia y la eficiencia. Los análisis útiles requieren la correlación de información de varios conjuntos de datos generados por la actividad diaria de los ingenieros de diseño y verificación.

Figura 3 y XNUMX

Figura 3 Canalizaciones de datos

Es un experimento mental útil para medir dónde se ubica su esfuerzo de verificación en relación con las preguntas en naranja, en cada una de las etapas anteriores del proceso de datos. Quizás sea sorprendente que no todos los equipos de ingeniería tengan un buen manejo de los datos que tienen, dónde están ubicados, qué tan limpios están y cómo explotarlos. Más adelante en el artículo exploramos la creación de la cultura de la curiosidad y las competencias necesarias para hacer posible esta transición.

La Figura 4 Desafíos de datos, a continuación, ilustra algunos de los desafíos que los equipos probablemente encontrarán al desarrollar los análisis necesarios para una buena toma de decisiones, impulsar procesos de verificación de mejoras importantes e indicar las inversiones necesarias en herramientas y hardware.

Figura 4 y XNUMX

Figura 4 Desafíos de datos

Estos desafíos no son exclusivos de la verificación de hardware, sino que deben superarse para alcanzar niveles básicos de capacidad analítica.

Derivar análisis de diversos conjuntos de datos puede resultar extremadamente complejo, especialmente cuando se trata de correlacionarlos. Un ejemplo sencillo sería ilustrar el descubrimiento de errores en diferentes etapas del ciclo de vida del producto para que pueda evaluar el progreso con respecto a su plan de verificación.

Otras preguntas de insight requieren una ingeniería de datos más compleja para proporcionar la información requerida. En empresas más pequeñas, esta tarea podría recaer en el equipo de ingeniería o podría subcontratarse. Como buenos “ingenieros de datos”, el equipo de verificación debe sentirse cómodo pensando en estos problemas.

Los equipos más grandes pueden tener el lujo de contar con recursos internos de analistas/ingeniería de datos para realizar estos desarrollos internamente. En ambos casos, los equipos de verificación deben dominar los desafíos de los datos para garantizar que obtengan lo que se necesita si se desea desarrollar o mejorar el análisis. Ver Paso 1: capacite a sus ingenieros para que piensen como analistas de datos.

La trampa de la calidad de los datos, el volumen de datos…

Nuestro objetivo en este documento técnico es analizar el “análisis de datos” en el contexto de la organización, automatización, limpieza y visualización de conjuntos de datos de verificación que la mayoría de los equipos ya tienen. Sin embargo, no se puede discutir este tema sin plantear la pregunta: –

¿Qué pasa con la IA? ¿Puedo usarlo?

Todo el mundo es consciente del potencial que ofrece el Machine Learning (ML) que actualmente se incorpora a las herramientas EDA (ver Paso 2: Explotar las herramientas EDA avanzadas), así como las oportunidades que ofrece la ciencia de datos para mejorar la orientación de la cobertura y el análisis de los datos para facilitar el análisis. Aunque este documento abordará estos temas, se centra principalmente en cómo hacer el mejor uso de los datos para generar mejores conocimientos sobre el proceso de verificación.

Figura 5 y XNUMX

Figura 5 Los conjuntos de datos pequeños y de baja calidad son barreras para desarrollar análisis o implementar con éxito técnicas avanzadas de ML/IA.

Aunque no hay cifras disponibles públicamente que muestren cuántos equipos de ingeniería han implementado con éxito el aprendizaje automático y la inteligencia artificial, es probable que muchos hayan encontrado problemas con la calidad de los datos o el tamaño de los conjuntos de datos.

En su artículo que invita a la reflexión, “Una encuesta sobre aplicaciones de aprendizaje automático en verificación funcional”, afirmaron Yu, Foster y Fitzpatrick, “Debido a la falta de grandes conjuntos de datos, gran parte de la investigación tiene que conformarse con técnicas de aprendizaje automático relativamente primitivas que exigen solo pequeños conjuntos de datos de entrenamiento con cientos de muestras. La situación ha impedido que se apliquen técnicas y algoritmos avanzados de ML”.

En la Figura 5 (Calidad de los datos), arriba, pequeñas cantidades de datos de verificación poco confiables son difíciles de analizar con algún grado de confianza; Trampa 1. En este caso, la opción plausible es invertir en limpiar sus datos y desarrollar análisis excelentes; no es fácil saltar al ML/AI en Nivel A2 Desde Trampa 1.

Grandes cantidades de información de baja calidad pueden ser muy difíciles de gestionar y comprender, lo que las hace inadecuadas para las técnicas de aprendizaje automático o inteligencia artificial, y mucho menos para cualquier ingeniería de datos necesaria para producir buenos análisis. Trampa 2. Al igual que con conjuntos de datos más pequeños, está indicada una operación de limpieza a gran escala. Por estas razones, la mala calidad de los datos y los conjuntos de datos más pequeños presentan desafíos importantes para las empresas que desean pasar a herramientas EDA habilitadas para ML y técnicas de inteligencia artificial más avanzadas.

Un paso más plausible y necesario para muchas organizaciones es hacer un mejor uso de los datos que tienen para crear análisis útiles que permitan una excelente toma de decisiones y una mejora continua.

Aunque “simplemente” crear buenos análisis puede parecer menos emocionante que pasar directamente al ML/AI en Nivel A2 , es posible que aún sean difíciles de implementar hasta que se hayan limpiado sus datos y se hayan superado algunos de los desafíos explorados en la Figura 4.

Suponiendo que tenga su ingeniería de datos organizada, construida sobre una base de datos de alta calidad y análisis impresionantes para iluminar esos rincones oscuros y ricos en errores, es hora de pensar qué conocimientos buscar.

Insight: "¿Es efectiva mi verificación?"

Volviendo a los “Insights”, muchos de los conjuntos de datos de verificación pueden clasificarse como insights de efectividad y eficiencia. Empecemos por la eficacia. ¿Qué significa eso para un equipo de verificación y quién más quiere saberlo?

La eficacia se puede describir como una función de la siguiente manera: –

Gráfico de efectividad

Es muy probable que cada una de las variables de la fórmula esté capturada en una base de datos separada y descrita mediante un conjunto de esquemas de datos.

La riqueza de los esquemas de datos utilizados para recopilarlos tiene un impacto directo en la calidad de los análisis que se pueden generar a partir de ellos.

Un "modelo de datos" conecta estas fuentes utilizando claves primarias para permitir la correlación de los datos. Una vez que el equipo haya identificado qué análisis se requieren, puede ser necesario elaborar los esquemas de datos.

La información sobre la eficacia requiere análisis que muestren la eficacia del banco de pruebas en términos de capacidad para realizar progresos en la verificación, definido como aumento de la cobertura y/o búsqueda de errores. Si un banco de pruebas no avanza en la cobertura o no encuentra errores, entonces podría resultar ineficaz, a menos que los objetivos de verificación ya se hayan cumplido por completo.

La utilidad de un buen análisis es la capacidad de analizar la eficacia del banco de pruebas de forma visual para que los equipos de desarrollo puedan realizar mejoras específicas en las implementaciones del banco de pruebas. Se logran mejoras continuas mediante iteraciones de refactorización de código, optimizaciones de rendimiento o reestructuración, con miras a aumentar la capacidad del banco de pruebas para detectar errores y cobertura con menos semillas o ciclos. Los análisis se utilizan en cada etapa para demostrar mejoras reales.

INSIGHT: "¿Mi banco de pruebas encuentra errores?"

Para ello, necesitamos esquemas de datos que permitan a los análisis visualizar y profundizar en la curva de errores a lo largo del tiempo. Esperamos ver una curva de errores acumulativos que se aplana y se satura con el tiempo; o una curva de tasa de errores que alcanza un máximo y luego cae hacia cero.

Mejor aún es correlacionar estas curvas de errores con el esfuerzo de verificación para dar una indicación real del esfuerzo de verificación versus los errores encontrados.

Y con una jerarquía de verificación como Unidad->Subsistema->Superior->Sistema, los análisis deben poder presentar los datos de errores versus esfuerzo en cada nivel y permitir a los usuarios ver cómo los diferentes niveles y diferentes unidades o sub -comparación de sistemas. Esta capacidad de análisis ofrece información sobre cuáles son los entornos de verificación eficaces y cuáles son aparentemente ineficaces. A partir de esto, los equipos pueden tomar decisiones sobre dónde invertir el esfuerzo de ingeniería para obtener el mayor rendimiento.

¿Qué significa eso en términos de datos?

Para hacer esto, necesitamos unir los datos de los errores con los datos de los resultados de la verificación para que podamos explorar cuántos ciclos de verificación se ejecutan entre la búsqueda de errores y observar esto durante el ciclo de vida del desarrollo del producto, ya que variará según la etapa del proceso. desarrollo en el que se encuentra el producto.

INSIGHT: “¿Mi banco de pruebas aumenta la cobertura?”

Los análisis también deben correlacionar los datos de cobertura con los datos del esfuerzo de verificación. Si los análisis revelan que la curva de errores está saturada y la cobertura está saturada, el equipo de ingeniería puede utilizar esta información para tomar decisiones sobre qué hacer a continuación; ¿Ejecutar más ciclos? ¿Correr menos ciclos? ¿Mejorar el entorno de verificación?

Además, con los datos de errores y cobertura recopilados a lo largo de todo el ciclo de vida de desarrollo del producto y todas las metodologías de verificación aplicadas, puede razonar sobre la eficacia relativa de cada metodología. es decir, debe considerar la efectividad en el contexto de todo el ciclo de vida de la verificación y la etapa en la que se encuentra. Por ejemplo, las pruebas unitarias pueden parecer ineficaces (no encuentran muchos errores) debido a que una verificación formal o de alto nivel anterior hizo un buen trabajo al eliminar la mayoría de los errores. Por lo tanto, se debe considerar todo el ciclo de vida de la verificación y el orden elegido para ejecutar las diversas metodologías.

Insight: "¿Es mi verificación eficiente?"

La segunda cuestión más importante se refiere a la eficiencia. Es posible que tenga un estímulo y una verificación efectivos, pero ¿se puede realizar la verificación con la mínima cantidad de recursos humanos y de plataforma, y ​​se puede entregar en el menor tiempo posible?

La eficiencia es función de lo siguiente: –

Gráfico de eficiencia

Para comprender la eficiencia, debe observar los detalles de:

  • Bancos de pruebas individuales para entender si han sido diseñado e implementado de forma óptima para obtener el máximo rendimiento con las condiciones dadas. metodología.
  • Regresión flujos de trabajo para comprender si están ejecutando trabajos de manera óptima y no desperdiciando recursos al volver a ejecutar innecesariamente conjuntos de regresión completos cuando las ejecuciones más específicas son más eficientes.
  • El disponible capacidades de la plataforma que se puede compartir entre varios equipos. ¿Existe una escasez de recursos que conduzca a ineficiencias en su utilización?
  • La actuación de la plataforma, tanto el hardware (cómputo, almacenamiento y red) como las herramientas EDA que ejecutan las cargas de trabajo de verificación.

Esta información nos dice cuán eficientemente se implementan los bancos de pruebas de simulación. Si un banco de pruebas es muy lento, consumirá niveles mucho mayores de recursos de licencias de computación y simulación. Es posible que sea necesario volver a implementar bancos de pruebas lentos para que se ejecuten más rápido. Esta pregunta se relaciona con la arquitectura y metodología del banco de pruebas de unidades o subsistemas.

Los conocimientos sobre eficiencia requieren análisis que revelen el desempeño relativo de los entornos de verificación rastreados a lo largo del tiempo para que se puedan identificar los cambios en el desempeño y se puedan observar e investigar los valores atípicos. Dado que los bancos de pruebas variarán según la arquitectura y la implementación, es de esperar cierto grado de variabilidad en el rendimiento, pero tener buenos paneles de análisis disponibles para monitorear estos entornos permite la detección temprana de los impactos en el rendimiento que pueden surgir de malas prácticas de codificación o degradaciones de plataforma/entorno/herramientas. Cuando los equipos pueden ver estos datos, pueden solucionar estos problemas.

Sin análisis, los equipos van a ciegas en cuanto a eficiencia. 

Recopilar datos de errores es las ¡El paso más importante hacia la capacidad analítica de nivel 1!

Hemos discutido el valor de los errores en la serie de artículos The Quest for Bugs, pero vale la pena reafirmar aquí por qué Bug Data es una de las fuentes más ricas de datos de verificación y puede generar los conocimientos más útiles, como la efectividad de la verificación.

Los errores son una fuente fantástica de conocimientos y aprendizaje, PERO ¡Solo si los coleccionas!

…y la recopilación de datos de errores de buena calidad es el desafío.

Con suficientes datos de errores precisos, puede obtener información sobre la efectividad de sus estrategias de verificación y la calidad de su diseño. (Nivel 1). Si observa todo el diseño, ¿algunas unidades o funciones producen más errores que otras y, de ser así, cuál es la causa? ¿Quizás se puedan tomar medidas para reducir la cantidad de errores que se introducen en el código? ¿Los datos de errores apuntan a puntos críticos de complejidad? ¿Cuál es la causa subyacente de estos errores? ¿Se pueden evitar? Desde la perspectiva de la eficacia de la verificación, ¿qué metodologías son las más eficaces para encontrar errores rápidamente? ¿Está gastando grandes recursos ejecutando ciclos de verificación que no encuentran errores?

¿Puede “desplazar hacia la izquierda” y encontrar esos errores en una etapa más temprana del ciclo de vida de desarrollo del producto y saturar la curva de errores antes, es decir, lanzar el producto antes?

Para responder a estas preguntas, debe asegurarse de recopilar suficientes datos de errores y de tener un esquema de errores adecuado que capture la información correcta sobre el descubrimiento de errores, sus impactos y sus causas fundamentales. Si tiene un conjunto de datos de errores rico, podrá profundizar en el análisis de errores para responder muchas de estas preguntas y tal vez exponer algunos conocimientos inesperados. ¡Bienvenido a Análisis de Nivel 1!

El desafío suele ser persuadir a sus equipos de ingeniería para que adquieran el hábito de registrar errores.

Es una cuestión de prácticas de ingeniería o de cultura de la ingeniería. Algunos equipos simplemente hacen esto como una parte natural de su trabajo, otros equipos están menos dispuestos y ven el registro de errores como una sobrecarga para avanzar.

Los equipos de ingeniería necesitan ver el valor concreto del análisis de errores como motivación para recopilar datos. Pero, por supuesto, es un problema del “huevo y la gallina”; sin datos de errores o datos de errores de mala calidad = sin análisis o análisis de bajo valor.

¿Cuándo es el momento adecuado para empezar a registrar errores? ¿Cómo se asegura de que los datos de errores sean completos y precisos?

Hay 3 motivadores clave para el registro de errores: –

  1. trabajo en equipo y comunicacion: la lista de tareas para desarrollar productos complejos (hardware o software) es larga y probablemente involucre a varias personas. A menos que los errores se registren y rastreen diligentemente, existe el riesgo de que se escapen debido a una mala práctica. A menudo ocurre que el reportero de errores y el solucionador de errores no son la misma persona, por lo que es necesario registrar y realizar un seguimiento de las comunicaciones de errores (clasificación, análisis y soluciones) para garantizar que nada se escape de la red.
  2. Seguimiento del progreso y aprobación: A medida que el proyecto pasa por el ciclo de vida de desarrollo del producto, es necesario comprender cómo se ve la curva de error en un momento dado. ¿Cuál es la tasa de errores actual? ¿Cuántos errores hay pendientes en cada punto de aprobación? ¿La curva de errores tiene la tendencia correcta en la dirección esperada? ¿Cuántos errores críticos tenemos en comparación con los errores mayores y menores?
  3. Mejora continua: Al analizar los datos de descubrimiento de errores y las causas fundamentales de los errores, podemos utilizar estos conocimientos para mejorar la eficacia y eficiencia de nuestras metodologías de diseño y verificación. Aquí es donde el aprendizaje continuo de los errores, tanto dentro de un proyecto como entre proyectos, realmente puede reducir los costos, mejorar la calidad y reducir el tiempo de comercialización de productos complejos.

Si puede recopilar datos de errores de forma precisa y coherente, muchos de los conocimientos anteriores estarán disponibles para usted. Además, si puede unir estos datos de errores con otras fuentes de datos interesantes, como datos de ejecución de pruebas, datos de hitos del proyecto o datos de consumo de recursos, entonces es posible obtener información poderosa adicional que iluminará el costo-beneficio de sus esfuerzos de ingeniería.

Paso 1: capacite a sus ingenieros para que piensen como analistas de datos

En la Figura 5 describimos las rutas para salir de las trampas de datos/volumen hacia las capacidades de Nivel 1 y 2. También podemos identificar tres etapas más específicas que deberán alcanzarse para avanzar.

Como mencionamos, el análisis de datos es una habilidad fundamental para los ingenieros de verificación, se den cuenta o no. A veces, sin embargo, los conceptos básicos de la fluidez de los datos no están ahí, y esto es algo en lo que puede capacitar a sus ingenieros. A menudo, el análisis de datos puede ser bastante básico; tal vez un extracto estático de datos que se visualiza como una tabla de Excel, o mejor como un gráfico de Excel. Estos análisis básicos son vistas estáticas de datos que tal vez deban actualizarse de forma manual y periódica y se presentan como instantáneas a tiempo para la presentación de informes del proyecto o el seguimiento del progreso.

El análisis en vivo y totalmente automatizado es el camino a seguir. Los ingenieros y gerentes deben poder acceder al análisis de datos en cualquier momento y confiar en que lo que ven son los datos más recientes, completos y precisos. Deben poder realizar estos análisis por sí mismos y no depender de ingenieros o analistas de datos para actualizar y entregar los análisis a pedido. Este requisito conduce a la necesidad de ofrecer visualizaciones fáciles de usar respaldadas por canales de datos automatizados que consumen datos en la fuente y los limpian y transforman en modelos de datos confiables sobre los cuales se pueden construir visualizaciones interactivas.

Por lo tanto, aquí se requieren más habilidades que una competencia básica con hojas de cálculo y gráficos.

Abogamos por la capacitación de algunas habilidades básicas de datos para ingenieros que les permitan comprender y presentar sus datos de una manera que conduzca a conocimientos poderosos. Algunas de estas actividades se pueden subcontratar a analistas de datos capacitados, pero un conocimiento básico en esta área garantiza que los ingenieros de verificación recopilen y analicen los conjuntos de datos correctos y comprendan qué datos se necesitan y cómo interpretarlos. También genera una perspectiva de datos (o fluidez de datos) donde los ingenieros comienzan a comprender cómo leer datos, cómo manipularlos y transformarlos, y cómo tener cuidado con los obstáculos que pueden producir resultados engañosos, como las relaciones de muchos a muchos entre elementos de datos. .

  • Captura de Datos: ¿De dónde provienen tus datos? ¿Cuál es la procedencia de los datos? ¿Se están recopilando todos ellos? Por lo general, esto implica alguna instrumentación de flujos de trabajo de verificación para capturar datos y enviarlos a un lago de datos. A su vez, eso significa que debe encontrar el esquema de datos correcto que capture todos los campos necesarios para respaldar el análisis. Este debería ser un proceso automatizado para que la captura de datos esté activada de forma predeterminada. Capture los datos, independientemente de si luego necesita filtrarlos y muestrearlos más adelante para los análisis.
  • Limpieza de datos: La mayoría de los datos sin procesar necesitan algún nivel de limpieza o procesamiento para eliminar valores nulos o duplicados, por ejemplo, corregir errores o entradas incorrectas o llenar vacíos de datos. Esto se puede hacer de forma interactiva, pero es mejor hacerlo mediante un procesamiento por lotes automatizado siempre que sea posible. La limpieza de datos se puede programar con Python NumPy y Los pandas bibliotecas, por ejemplo, donde se pueden realizar potentes operaciones de datos en marcos de datos con solo unos pocos pasos. (Muchos ingenieros de verificación ya utilizarán Python para la creación de secuencias de comandos y el procesamiento del flujo de trabajo de verificación, por lo que agregar estas bibliotecas de análisis de datos y los conceptos relacionados con la manipulación de marcos de datos no debería ser un paso difícil).
  • Ingeniería de datos: Este es el paso donde los datos se transforman y manipulan en un formato adecuado para la visualización de datos. Esto puede implicar unir y fusionar diferentes fuentes de datos para que sean posibles correlaciones importantes que proporcionen información clave a partir de los datos. Consulte la Figura 4 Desafíos de datos. A veces llamado modelo de datos, es el esquema que controla cómo se unen las diferentes tablas de datos, utilizando elementos comunes (claves primarias) que las vinculan. También puede implicar pivotes, agregaciones, resúmenes o la generación de elementos de datos derivados o calculados. Por ejemplo, los equipos de verificación podrían querer correlacionar los datos de los resultados de la ejecución del banco de pruebas de simulación con los datos de seguimiento de errores para comprender qué tan efectivos son los diferentes bancos de pruebas para encontrar errores en el RTL. Además, la competencia en ingeniería de datos podría extenderse a las bases de datos: cómo configurar bases de datos estructuradas como MySQL o bases de datos no estructuradas (o Data Lakes) como MongoDB o Hadoop, por ejemplo. Hay mucho que aprender en este dominio, y es un área donde los ingenieros y analistas de datos se especializarán, por lo que, como ingeniero de verificación o ingeniero de diseño, puede ser bueno comprender esta disciplina, pero subcontratar el trabajo de ingeniería de datos a especialistas en datos.
  • Consulta de datos: Esto puede ser más un conjunto de habilidades de ingeniería de datos, pero algunas capacidades básicas de SQL pueden ser útiles para respaldar la exploración temprana de conjuntos de datos, antes de que estén disponibles las visualizaciones de datos completas. Explorar conjuntos de datos es una competencia clave cuando se presentan nuevos datos y antes de establecer cualquier análisis automatizado. SQL es una competencia central para la mayoría de los analistas de datos.
  • Visualización de datos: Finalmente, la parte que brindará resultados e información clave es donde se visualizan los datos y el usuario final puede interactuar con ellos. A veces se la denomina “inteligencia empresarial”, ya que presenta inteligencia o conocimientos sobre el estado del negocio (o el estado de un proyecto de desarrollo de producto). No se debe subestimar la importancia de aprender buenas habilidades de visualización de datos, y existen múltiples buenas opciones de herramientas que son divertidas de aprender y pueden ofrecer visualizaciones impresionantes muy rápidamente, por ejemplo, PowerBI o Tableau. Aprender a utilizar estas herramientas de manera efectiva genera interés y entusiasmo reales en torno a los datos, por lo que es una habilidad básica que vale la pena agregar al conjunto de habilidades del ingeniero de diseño o verificación.

Paso 2: Explotar las herramientas EDA avanzadas

La industria EDA ha estado trabajando en formas de explotar la IA y el ML para mejorar su oferta de herramientas durante varios años. Esto es posible tanto por los grandes volúmenes de datos generados por muchas herramientas de verificación de EDA como por la aparición y maduración de algoritmos de aprendizaje automático generales que pueden ser adecuados para muchos problemas de datos de verificación. Estas herramientas a menudo se ofrecen como nuevas versiones de las herramientas existentes sobre las que se puede obtener licencia, o como mejoras de las herramientas existentes donde se mejora el rendimiento y la eficiencia gracias al aprendizaje automático interno. Es posible que el usuario final no necesite saber que las herramientas están utilizando el aprendizaje automático, ni cambiar la forma en que las usa, pero las herramientas funcionarán mejor. Esto presenta una barrera baja para que sus equipos de verificación adopten herramientas más avanzadas si decide hacerlo, y sin la necesidad de capacitarse como científicos de datos o aprender ML. No vamos a discutir las ofertas específicas de los proveedores de EDA ni intentaremos estudiar el mercado aquí. Nuestro punto es este:

Se debe alentar a los equipos de verificación a explorar y evaluar las ofertas disponibles...

…para ver si existe una relación costo-beneficio para sus flujos de trabajo y sus ciclos de vida de desarrollo de productos. Dado que la industria EDA está en constante evolución, las herramientas que se ofrecen y las herramientas de verificación han sido un área de alta innovación en la industria EDA durante algún tiempo. Es responsabilidad del equipo de verificación mantenerse al tanto de los últimos desarrollos e interactuar con los proveedores de EDA para garantizar que sus requisitos actuales y futuros puedan cumplirse mediante las hojas de ruta tecnológicas del proveedor de EDA.

Algunas de las formas (pero no todas) en las que ML está mejorando las ofertas de herramientas EDA se encuentran en las siguientes áreas: –

  • Aceleración de depuración mediante agrupación de fallos automatizada y análisis de firmas.
  • Optimización de la ejecución para garantizar que se utilicen configuraciones óptimas de herramientas para las ejecuciones de simulación.
  • Optimización de selecciones formales de motores para verificación formal.
  • Aceleración del cierre de cobertura mediante ranking y optimización de selección de pruebas.

Puede pensar en los flujos de trabajo de verificación como un conjunto de entradas y salidas de datos, como se muestra a continuación. Tanto los conjuntos de datos de entrada como los conjuntos de datos de salida generados pueden ser candidatos para oportunidades de aprendizaje automático. Sabemos cuánto esfuerzo se puede dedicar al análisis de cobertura y al análisis de los resultados de las pruebas. Incluso pequeñas mejoras en la eficiencia y eficacia en estas áreas clave pueden generar ahorros valiosos en costos, calidad y tiempo de comercialización.

Figura 6 y XNUMX

Figura 6 ML para herramientas EDA

Paso 3: capacite a sus ingenieros para que piensen como científicos de datos

Hasta ahora hemos hablado de las habilidades básicas necesarias para realizar un análisis de datos competente, pero, por supuesto, existe toda una rama del análisis de datos a la que a menudo se hace referencia como ciencia de datos, que es apasionante y atractiva porque nos ofrece oportunidades para explotar nuestros datos. de diferentes maneras y obtener más información a partir de los datos que tal vez no se puedan lograr solo con visualizaciones de datos. A menudo denominada ML o Machine Learning, existe una disciplina bien establecida que es accesible para todos con una formación un poco más básica. Hay bibliotecas de algoritmos listos para usar disponibles; Puedes encontrar muchos de estos convenientemente incluidos en Python. scikit-aprender biblioteca por ejemplo. A los ingenieros de verificación curiosos les encanta innovar y resolver problemas relacionados con la eficiencia y eficacia de la verificación. Se trata de problemas interesantes y desafiantes, y resolverlos aprendiendo y aplicando nuevas habilidades de aprendizaje automático puede resultar muy motivador. Aprender estas nuevas habilidades también es divertido y disfrutable, y existen muchas plataformas excelentes de aprendizaje en línea que pueden llevarte de cero a héroe en muy poco tiempo, por ejemplo, búsqueda de datos, Campamento de datos, udemy, coursera, academia de código, para nombrar unos pocos.

Si su equipo de ingeniería domina las habilidades básicas de visualización y análisis de datos, su canal de datos es limpio y preciso, y está recopilando suficientes datos, entonces hay muchos problemas de optimización en la verificación que pueden estar maduros para un enfoque de ML (por ejemplo, reducción de conjuntos de regresión). y optimización, modelado de predicción de demandas de recursos, optimización del cierre de cobertura, etc.

Más allá de esto, hoy en día hay mucho entusiasmo en torno a la IA, especialmente la aplicación de la IA generativa a problemas como la generación de pruebas o la escritura de códigos. No vamos a explorar ese tema aquí, pero cuando los ingenieros de verificación comiencen a pensar y actuar como científicos de datos, puede haber muchas oportunidades para realizar mejoras tangibles en la forma en que se verifican los diseños complejos utilizando menos recursos, en menos tiempo y entregando productos de mayor calidad.

Resumen

La verificación de hardware es un problema que requiere muchos datos.

Los ingenieros de verificación lo saben desde hace algún tiempo y su trabajo diario implica la recopilación, el procesamiento y la generación de informes sobre algunos conjuntos de datos de gran tamaño. La razón por la que es un problema con muchos datos es que la verificación es intrínsecamente un problema abierto. Los equipos de ingeniería necesitan análisis profundos para que este proceso abierto sea mensurable y finito. Algunos equipos de ingeniería todavía están trabajando con análisis y visualización a nivel de hoja de cálculo, a menudo utilizando instantáneas estáticas de datos y manipulaciones manuales de datos cuya actualización requiere mucho tiempo. Puede haber muchas fuentes de datos diferentes contenidas en muchos sistemas diferentes, lo que dificulta unir datos y establecer correlaciones reveladoras.

Para muchos, el desafío es cómo explotar los datos de verificación con análisis de datos que revelarán oportunidades significativas para mejorar la verificación de hardware.

Hay disciplinas maduras disponibles para ayudar con esto, especialmente en las áreas de ingeniería de datos, análisis de datos y visualización de datos. Los equipos de ingeniería deben mejorar sus habilidades en análisis de datos modernos o contratar ingenieros de datos, analistas de datos y científicos de datos profesionales para incorporar estas capacidades al proceso de desarrollo de productos. El punto final es un conjunto de análisis interactivos y en tiempo real que son intuitivos, accesibles, precisos y de autoservicio. Los consumidores de análisis ya no deberían necesitar presentar una solicitud para ver un informe actualizado. Deben acceder a las visualizaciones ellos mismos y entender cómo profundizar y filtrar la vista que necesitan, que pueden guardar o incrustar como vista favorita, sabiendo que se trata de datos en tiempo real y confiando en que los datos son precisos. La generación de informes se convierte en una tarea menos onerosa cuando tienes análisis en vivo a tu alcance. La disponibilidad y accesibilidad mejoradas significa que el análisis se delega a aquellos que necesitan los datos y, lo que es más, la curiosidad debería revelar conocimientos previamente desconocidos cuando los datos son mucho más fáciles de ver y explorar.

Si no hace nada más, refine sus comportamientos y procesos de captura de datos de errores...

… porque el análisis de errores puede revelar ideas sobre las que se puede actuar en el corto plazo.

Ese es el análisis de datos de verificación de referencia al que debemos aspirar. Haz esto primero. Establezca una canalización de datos limpia, precisa y completa donde el punto final sean fantásticas visualizaciones de datos explorables. Más allá de eso, existen más posibilidades de explorar conjuntos de datos más profundamente y explotar técnicas más avanzadas, como el aprendizaje automático o la inteligencia artificial, para comprender patrones en los datos nunca antes vistos y crear ciclos de retroalimentación en los procesos y flujos de trabajo para optimizar y reducir el tiempo, el esfuerzo y los costos. Observamos que todos los proveedores principales de herramientas de verificación EDA ya están desarrollando ML bajo el capó para muchas de sus ofertas de herramientas avanzadas. Estos se pueden explotar hoy sin necesidad de capacitar a sus ingenieros como científicos de datos. La mayoría de las actividades de verificación implican algún tipo de iteración o refinamiento hacia un resultado. Es posible que pueda llegar allí con un porcentaje de precisión aceptable en una fracción del tiempo utilizando ML/AI. Los equipos más avanzados o los equipos que contratan a científicos de datos capacitados pueden obtener estos beneficios a medida que crece la madurez de los datos y los equipos de ingeniería adoptan una cultura de datos sólida.

Autores:
Bryan Dickman, Vallytic Consulting Ltd.,
Joe Convey, Acuerdo Ltd.

Lea también

La búsqueda de errores: "Shift-Izquierda, ¿derecha?"

La búsqueda de errores: "¡Corregir por diseño!"

La búsqueda de errores: errores de poder

La búsqueda de errores: "ciclos profundos"

La búsqueda de errores: dilemas de la verificación de hardware

Comparte esta publicación a través de:

punto_img

Información más reciente

punto_img