Cuáles son las mejores prácticas para los Lenguajes de Descripción de Hardware (Verilog, VHDL, etc.) [cerrado]

Una especie de hilo viejo, pero quería poner en mi $0.02. Esto no es realmente específico de Verilog / VHDL.. más sobre el diseño de hardware en general... diseño específicamente sintetizable para ASICs personalizados.

Esta es mi opinión basada en años de experiencia en la industria (en contraposición a la académica) en diseño. No están en un orden particular

Mi declaración paraguas es Diseñar para la ejecución de validación. En el diseño de hardware, la validación es primordial. Los errores son mucho más caros cuando se encuentra en silicio real. No puedes simplemente recompilar. Por lo tanto, al pre-silicio se le da mucho más enfoque.

• Conozca la diferencia entre rutas de control y rutas de datos. Esto le permite crear código mucho más elegante y mantenible. También le permite guardar puertas y minimizar la propagación X. Por ejemplo, las rutas de datos nunca deben necesitar fallos restablecibles, las rutas de control siempre deben necesitarlo.

• Probar la funcionalidad antes de la validación. Ya sea a través de una enfoque formal o a través de formas de onda. Esto tiene muchas ventajas, voy a explicar 2. Primero, le ahorrará tiempo perdido pelando cebolla a través de problemas. A diferencia de muchos diseños de nivel de aplicación (esp mientras se aprende) y la mayoría del trabajo del curso, el tiempo de respuesta para los cambios de código es muy grande (de 10 minutos a días, dependiendo de la complejidad). Cada vez que cambia el código, necesita pasar por la elaboración, la comprobación de pelusa, la compilación, la presentación de la forma de onda y, finalmente, la simulación real.. que puede mismo horario. En segundo lugar, es mucho menos probable que tenga casos difíciles de golpear la esquina. Tenga en cuenta que esto es con respecto a la validación pre-silicio. Estos seguramente golpearán en post-silicio que cuesta un montón de$ $ $. Confía en mí, el costo inicial de probar la funcionalidad minimiza en gran medida el riesgo y vale la pena el esfuerzo. Esto a veces es difícil de convencer a los graduados universitarios recientes.

• Come "trozos de pollo". Chicken bits son bits en MMIO establecidos a través del controlador para desactivar una característica en silicio. Se pretende revertir los cambios realizados en los que la confianza no es alta (la confianza es directamente proporcional a los esfuerzos de validación). Es casi imposible golpear todos los estados posibles en pre-silicio. La confianza en su diseño no se puede cumplir realmente hasta que se pruebe en post-silicio. Incluso si solo hay 1 estado que es golpeado 0.000005% del tiempo que expone el error, golpeará en post-silicio, pero no necesariamente en pre-silicio.

• Evitar excepciones en el control camino a toda costa. Cada nueva excepción que tenga duplica sus esfuerzos de validación. Esto es difícil de explicar. Digamos que hay un bloque DMA que guardará los datos en la memoria que otro bloque usará. Digamos que la estructura de datos guardada depende de que se realice alguna función. Si decidió diseñar de manera que la estructura de datos guardada fuera diferente entre diferentes funciones, simplemente multiplicó sus esfuerzos de validación por el número de funciones DMA. Si se sigue esta regla, el la estructura de datos guardada sería un súper conjunto de todos los datos disponibles para cada función donde se codifican las ubicaciones de contenido. Una vez que la lógica de guardado de DMA se valida para 1 función, se valida para todas las funciones.

• Minimizar interfaces (leer minimizar rutas de control). Esto está relacionado con minimizar las excepciones. En primer lugar, cada nueva interfaz requiere validación. Esto incluye nuevos comprobadores / rastreadores, aserciones, puntos de cobertura y modelos funcionales de bus en su banco de pruebas. En segundo lugar, puede aumentar sus esfuerzos de validación exponencialmente! Digamos que tiene 1 interfaz para leer datos en cachés. Ahora digamos (por alguna extraña razón) que usted decide que desea otra interfaz para leer la memoria principal. Sólo se cuadruplicó su validación. Ahora necesita validar estas combinaciones en cualquier momento n :

  • no cache read, no memory read{[12]]}
  • no cache read, memory read{[12]]}
  • cache read, no memory read{[12]]}
  • cache read, memoria leer

• Comprender y comunicar suposiciones. La falta de esta es la razón principal para bloquear los problemas de comunicación. Podrías tener un bloque perfecto completamente validado.. sin embargo, sin entender todas las suposiciones, su bloque fallará cuando esté conectado.

• Minimizar los estados potenciales. Cuanto menos estados (intencionados o no) tenga un diseño, menor será el esfuerzo necesario para validarlo. Es una buena práctica agrupar funciones similares en 1 nivel superior función (como secuenciadores y árbitros). Es muy difícil identificar y definir esta función de alto nivel de manera que abarque tantas funciones más pequeñas como sea posible, pero al hacerlo elimina enormemente el estado y, a su vez, el potencial de errores.

• Siempre proporcione una señal fuerte saliendo de su bloque. La mayoría de las veces flopping es la solución. No tiene idea de lo que el(los) bloque (s) de punto final harán con él. Podría encontrarse con problemas de tiempo que pueden tener un impacto directo en su implementación perfecta.

• Evite los FSM de tipo harinoso a menos que el rendimiento se vea afectado negativamente. Harinosa FSM son más propensos a producir problemas de tiempo sobre Moore

• .. y finalmente el que más me disgusta:" si no está roto, no lo arregles " Debido al riesgo involucrado y el alto costo de los errores, muchas veces el hacking es una solución más práctica para resolver problemas. Otros han eludido esto mencionando la utilización de componente.

En cuanto a la comparación con más tradicional diseño de software:

• La programación discreta impulsada por eventos es un paradigma completamente diferente. La gente ve la sintaxis de verilog y piensa "oh, es como C"... sin embargo, esto no puede estar más lejos de la verdad. Aunque la sintaxis es similar, uno debe pensar diferente. Por ejemplo, un depurador tradicional carece prácticamente de sentido en RTL sintetizable (el diseño del banco de pruebas es diferente). Formas de onda encendidas el papel es la mejor herramienta disponible. Sin embargo, dicho esto, el diseño FSM a veces puede imitar la programación procedimental. Las personas con un fondo de software tienden a volverse locas con FSMs (sé que lo hice al principio).

• Sistema Verilog tiene montones y montones (y montones) de testbench características específicas. Está completamente orientado a objetos. En cuanto al diseño del banco de pruebas, es muy similar al diseño de software tradicional. Sin embargo, tiene 1 dimensión más asociada a ella, la del tiempo. carrera las condiciones y los retrasos del protocolo deben tenerse en cuenta

• En cuanto a la validación, también es diferente (y la misma). Hay 3 enfoques principales;

  • Verificación propagativa formal (FPV): Usted demuestra a través de la lógica que siempre funcionará
  • Pruebas aleatorias dirigidas. Establezca aleatoriamente los retrasos, los valores de entrada y la habilitación de características según lo definido por una semilla. dirigido significa que la semilla pone peso en caminos que tienen menos confianza. Este enfoque utiliza la cobertura puntos para indicar la salud
  • Pruebas de enfoque. Esto es similar a las pruebas de software tradicionales

... para completar, también necesito discutir las mejores prácticas de diseño de bancos de pruebas... pero eso es para otro día

Lo siento por la longitud.. Yo estaba en "La Zona" :)

HDL como Verilog y VHDL realmente parecen fomentar el código espagueti. La mayoría de los módulos consisten en varios bloques' always '(Verilog) o' process ' (VHDL) que pueden estar en cualquier orden. El algoritmo o función general del módulo a menudo está totalmente oscurecido. Averiguar cómo funciona el código (si no lo escribiste) es un proceso doloroso.

Hace unos años me encontré con este documento que describe un método más estructurado para el diseño VHDL. La idea básica es que cada módulo tiene solo 2 bloques de proceso. Uno para el código combinatorio, y otro para síncrono (los registros). Es ideal para producir código legible y mantenible.

• En HDL, algunas partes del código pueden funcionar al mismo tiempo, por ejemplo, dos líneas de código "pueden funcionar" al mismo tiempo, esto es una ventaja, para usar sabiamente. esto es algo que un programador que está acostumbrado a los lenguajes línea por línea puede encontrar difícil de entender al principio:

  • Se pueden crear canalizaciones largas y específicas para sus necesidades.
  • Puede hacer que sus módulos grandes funcionen al mismo tiempo.
  • en lugar de una unidad para hacer una acción repetida en diferentes datos, puede crear varias unidades, y hacer el trabajo en paralelo.

• Se debe prestar especial atención al proceso de arranque: una vez que su chip está funcional, ha hecho un gran camino.

Depurar en hardware suele ser mucho más difícil que depurar software, así que:

• Código simple es preferible, a veces hay otras formas de acelerar su código, después de ya se está ejecutando, por ejemplo, utilizando un chip de mayor velocidad, etc'.

• Evite protocolos "inteligentes" entre componentes.

• Un código de trabajo en HDL es más valioso que en otro software, ya que el hardware es tan difícil de depurar, por lo que reutilizar, y también considerar el uso de "bibliotecas" de módulos que algunos son gratuitos y otros vendidos.

• El diseño debe tener en cuenta no solo los errores en el código HDL, sino también las fallas en el chip que está programando y en otros dispositivos de hardware que interactúan con el chip, por lo que uno realmente debe pensar en un diseño que es fácil de comprobar.

Algunos consejos de depuración:

• Si un diseño incluye varios bloques de construcción, uno probablemente querría crear líneas desde las interfaces entre esos bloques hasta puntos de prueba fuera del chip.

• Usted querrá guardar suficientes líneas en su diseño para desviar datos interesantes para ser inspeccionados con dispositivos externos. también puede utilizar estas líneas, y su código como una forma de decirle el estado actual de ejecución - por ejemplo, si recibe datos en algunos punto, se escribe algún valor a las líneas, en una etapa posterior de la ejecución se escribe otro valor, etc'

  Si su chip es reconfigurable, esto será aún más útil, ya que puede personalizar pruebas específicas y reprogramar las salidas para cada prueba a medida que avanza (esto se ve muy bien con los led :). )

Editar:

Por protocolos inteligentes, me refiero a que si dos de sus unidades físicas se conectan, deben comunicarse con el protocolo de comunicación más simple disponible. es decir, no utilice ningún sofisticado protocolos caseros, entre ellos.

La razón, es esta - Fidning bugs "dentro" de un FPGA/ASIC es muy fácil ya que tiene simuladores. Así que si está seguro de que los datos vienen como lo desea, y sale como su programa lo envía, has llegado a Hardware utopia-ser capaz de trabajar a nivel de software:) (con el simulador). Pero si sus datos no llegan a usted, la forma en que desea que, y usted tiene para averiguar por qué... tendrás que conectarte a las líneas, y eso no es tan fácil.

Encontrar un bug en las líneas, es difícil ya que tiene que conectarse a las líneas con equipos especiales, que registran los estados de las líneas, en diferentes momentos, y tendrá que asegurarse de que sus líneas actúen de acuerdo con el protocolo.

Si necesita conectar dos de sus unidades físicas, haga que el" protocolo " sea lo más simple posible , hasta el punto de que no se llamará protocolo :) Por ejemplo, si el las unidades comparten un reloj, agregan x líneas de datos entre ellas, y hacen que una unidad las escriba y la otra unidad las lea, pasando así una "palabra" que tiene x bits entre ellas en cada caída de reloj, por ejemplo. Si tiene FPGA, si la velocidad de reloj original es demasiado rápida para datos paralelos, puede controlar la velocidad de esto, de acuerdo con sus experimentos, por ejemplo, haciendo que los datos permanezcan en líneas de al menos 't' ciclos de reloj, etc. Supongo que la transferencia de datos en paralelo es más simple, ya que puede trabajar con menor las tasas de reloj y obtener las mismas actuaciones, sin la necesidad de dividir sus palabras en una unidad, y volver a montar en la otra. (esperemos que no haya retraso entre el 'reloj' que recibe cada unidad). Incluso esto es probablemente demasiado complejo:)

Con respecto a SPI, I2C, etc.' No he implementado ninguno de ellos, Puedo decir que he conectado las piernas de dos FPGA corriendo desde el mismo reloj, (no recuerdo la formación exacta de resistencias en el medio), a tasas mucho más altas, así que realmente no puedo pensar en una buena razón para usarlos, como la forma principal de pasar datos entre sus propias FPGA, a menos que las FPGA estén ubicadas muy lejos una de otra, que es una razón para usar un bus serie en lugar de un bus paralelo.

JTAG es utilizado por algunas compañías FPGA, para probar/programar sus productos, pero no está seguro de si se utiliza como forma de transportar datos a altas velocidades, y es un protocolo... (todavía uno que puede tener algún soporte incorporado en el chip).

Si tiene que implementar cualquier protocolo conocido, considere usar un código HDL pre-hecho para esto - que se puede encontrar o comprar.

Esta es la pregunta que requiere los 10 mandamientos de JBDAVID para el diseño de Hardware.

1. Utilice el Control de Revisiones/Versiones, al igual que en el Software. SVN y Hg son gratis.
2. Requiere que el código pase la comprobación de sintaxis antes del check-in. Una herramienta de PELUSA es mejor.
3. Utilice un Lenguaje de Verificación de Hardware completo para la Verificación del diseño. System-Verilog es casi una opción segura.
4. Seguimiento de errores. Bugzilla y GNATS son herramientas gratuitas. FogBugz requiere un poco de $
5. Uso Aserciones para detectar problemas con un uso incorrecto.
6. La Tríada de Cobertura permite un diseño estable: Medir la cobertura de código, la cobertura funcional y la cobertura de Aserción tanto en simulación como en herramientas formales.
7. El poder es el rey: usa CPF o UPF para capturar, hacer cumplir y verificar tu Intención de Poder.
8. el diseño real es a menudo una señal mixta, Use un lenguaje de señal Mixta para verificar lo analógico con lo digital. Verilog-AMS es una de esas soluciones. Pero no te pases. Realnumber modelado puede lograr la mayoría de los aspectos funcionales del comportamiento de señal mixta.
9. Utilice la aceleración de hardware para validar el Software que tiene que trabajar con el silicio!
10. Los editores de texto compatibles con la sintaxis para su HDL/HVL son un requisito mínimo para el IDE de desarrollador.

Para FPGAs, Xilinx tiene esta gran página (falta, nueva ubicación por determinar). Casi todos se aplicarían a otros proveedores de FPGA, o tendrían reglas equivalentes. Una gran cantidad es aplicable a los diseños ASIC.

Altera tiene Estilos de codificación HDL Recomendados (PDF) y Recomendaciones de diseño para Altera Dispositivos y el Asistente de Diseño Quartus II. Altera tiene este curso de pago. Sin embargo, se trata más de productividad. No tengo otra información de lo bueno que es.