Cómo evitar que los proyectos basados ​​en FPGA se desvíen

Durante el transcurso de mi carrera, he estado involucrado en el desarrollo de varios diseños de FPGA para algunos proyectos realmente interesantes. Lamentablemente, también he estado involucrado en el rescate de varios diseños de FPGA que se han descarriado. Mientras trabajaba en estos diseños de problemas, se hizo evidente que, aunque las aplicaciones de destino y los miembros de los equipos de desarrollo eran diferentes, los diseños compartían algunos puntos en común que los condenaban al fracaso antes de que el primer ingeniero siquiera se sentara a escribir la primera línea. de código HDL.

Con esto en mente, pensé que podría resolver cinco problemas comunes que he observado como parte del rescate de estos proyectos. Estos problemas son los siguientes:

N.º 1: La primera preocupación no se relaciona solo con el desarrollo basado en FPGA, sino con la ingeniería en general. El problema es no tener una línea base de requisitos estable al comenzar. Siempre existe el deseo de comenzar el proyecto mientras los requisitos aún están madurando sobre la base de que es necesario demostrar el progreso. Sin embargo, si saltamos y comenzamos a desarrollar sin comprender completamente los requisitos, entonces, con demasiada frecuencia, cualquier progreso inicial resulta ser falso y realizar correcciones posteriores introduce retrasos y costos adicionales. Lo que realmente hace comenzar demasiado pronto es introducir riesgos en el desarrollo, y este riesgo debe mitigarse. Aprecio que, dependiendo de la aplicación en cuestión, la profundidad y el detalle de los requisitos pueden escalar. Esperaría muchos más requisitos, y más detallados, para un sistema SIL4 que para un sistema comercial. Sin embargo, lo más largo y corto es que, si los requisitos no se acuerdan y no se establecen como base desde el principio, habrá un deslizamiento del alcance. Aunque el diseño puede haber comenzado con una arquitectura sensible a los requisitos tal como se entienden, se volverá cada vez más complicado cuando los desarrolladores intenten introducir nuevas funcionalidades a medida que madura la línea de base. En poco tiempo, algo se romperá.

N.º 2: Habiendo entendido la situación de los requisitos, todos los miembros del equipo deben comprender el plan para desarrollar la FPGA. Por lo tanto, es una buena idea tener un plan que defina el enfoque que se seguirá desde el inicio hasta la entrega, identificando los pasos principales involucrados y las puertas de revisión de ingeniería que se aplicarán durante el proceso de desarrollo. Junto con el plan, también necesitamos documentar la arquitectura y el diseño, identificando cada una de las funciones principales, decidiendo qué funciones se van a desarrollar recientemente y cuáles son para aprovechar la IP de terceros o reutilizar la IP existente (más sobre esto más tarde). Esta documentación combinada de plan, arquitectura y descripción del diseño permitirá al equipo de ingeniería comprender claramente la tarea en cuestión. También podemos rastrear todas las funciones hasta el conjunto de requisitos para garantizar que el enfoque propuesto aborde todos los requisitos de alto nivel.

N.º 3: El diseño de los módulos y la FPGA en general llevará tiempo; Sin embargo, lo que llevará más tiempo es verificar el diseño y asegurarse de que cumpla con sus requisitos. Esta verificación debe abarcar no solo la funcionalidad lógica, sino que también debe realizarse en todas las posibles condiciones de funcionamiento del dispositivo. A su vez, esto significa que es necesario desarrollar una clara estrategia de verificación para el diseño; ya no se trata simplemente de escribir el código, realizar algunas simulaciones y luego lanzar el diseño al hardware.

N.º 4: A veces, todos nos acercamos tanto a las cosas y nos centramos en nuestro pensamiento que se vuelve difícil ver cuando nos hemos perdido algo. Para eso se inventaron las revisiones de diseño de ingeniería. Al realizar estas revisiones, podemos asegurarnos de que estamos siguiendo las buenas prácticas de ingeniería y cumpliendo con los estándares de desarrollo internos. De manera significativa, también brindan la capacidad para que los ingenieros independientes examinen el diseño, su arquitectura e implementación, para asegurarse de que proporcionará la funcionalidad requerida. Si no revisamos el diseño a medida que avanza, no lograremos mejorar la calidad y aumentaremos los problemas de integración posteriores.

N.º 5: Hasta ahora, es posible que haya notado que la mayoría de los puntos que he planteado están relacionados con el proceso y aspectos de ingeniería más amplios, en contraposición a la codificación del diseño en sí. Por supuesto, desarrollar el código es importante, pero también es importante asegurarse de que estamos aprovechando la IP de terceros y reutilizando la IP interna. Idealmente, deberíamos reutilizar tantos bloques de IP existentes de nuestra biblioteca como sea posible. Cuando esto no sea posible, por supuesto, necesitaremos desarrollar nuevos módulos. En este caso, la creación de estos nuevos módulos de tal manera que se puedan reutilizar en proyectos futuros debe ser lo más importante en nuestras mentes. Para ayudarnos a crear estos nuevos bloques, deberíamos considerar el uso de herramientas de síntesis de alto nivel (HLS). Al permitirnos trabajar a un nivel más alto de abstracción, estas herramientas brindan la capacidad de explorar más fácilmente el espacio de la solución y reducir el riesgo, el tiempo de desarrollo y los costos.

Los puntos presentados anteriormente son solo algunas de las cosas que he notado al rescatar diseños FPGA. Me interesaría mucho conocer su opinión sobre los proyectos que se desviaron.