¿Cómo alguien diseña inicialmente un sistema digital para HDL?

Así que esta semana he estado presionando mucho el código de ejemplo en un intento de comprender mejor algunos conceptos básicos de diseño de HDL, específicamente FPGA con VHDL. El libro que estoy usando (si alguien está interesado) es "FPGA PROTOTYPING BY VHDL EXAMPLES" de Pong P. Chu.

Después de algunos ejemplos, estoy empezando a preguntarme.

¿Cómo alguien diseña inicialmente un sistema digital para HDL?

(¿Diagrama de flujo/Diagrama de bloques? ¿Lista de señales? etc.)

Por ejemplo, me encanta usar Logisim para desarrollar circuitos digitales simples. La interfaz gráfica es fácil de seguir y puedo obtener simulaciones sobre la marcha sin toda la síntesis. Pero cuando estoy satisfecho con mi diseño Logisim, encuentro difícil transferir ese diseño a HDL.

¿Hay alguna manera de entender cómo debe estructurar su diseño HDL, o solo viene con la práctica?

Respuestas (2)

Por lo general, tomo un enfoque de diseño de arriba hacia abajo y empiezo dibujando un diagrama de bloques que muestra las interfaces entre los bloques de nivel superior. Luego dibujo diagramas adicionales que representan las implementaciones de los bloques de nivel superior en términos de bloques de nivel inferior.

Esta jerarquía de diagramas de bloques se traduce prácticamente directamente en la jerarquía de los módulos HDL. Una vez que llego a un nivel de detalle lo suficientemente bajo en los diagramas de bloques, empiezo a codificar y dejo de dibujar diagramas.

Los diagramas de bloques también funcionan como diagramas de flujo de datos, ya que muestran en cada etapa cómo fluyen los datos de un módulo a otro.

Cuando se trata de interfaces específicas entre módulos, también dibujo diagramas de tiempo que muestran los detalles del protocolo de interfaz. También uso diagramas de tiempo para realizar un seguimiento del flujo de datos a través de las etapas de canalización dentro de un módulo. En ambos casos, estos diagramas sirven como referencia cuando se observan formas de onda en el simulador durante la verificación.

+1 comience con una ruta de datos, luego identifique las señales de control, luego diseñe su lógica de control (es decir, máquinas de estado)
Justo antes de comenzar a codificar los bloques, trato de escribir el mapa de registro y definir todos los campos de registro. Por ejemplo, STATUS[0]=FIFO_empty, ... Me ayuda a mantener una visión general de las funciones que aún deben implementarse durante la fase de código.

Los libros y las conferencias le dirán que hay dos formas: de abajo hacia arriba y de arriba hacia abajo.

En mi opción, los principiantes deberían comenzar de arriba hacia abajo, porque saben lo que quieren (el sistema) y pueden dividirlo en módulos como lo describió Dave.

Si reunió algo de experiencia, probablemente tendrá algún tipo de colección de módulos o su objetivo de diseño no es construir un sistema sino un componente como un controlador VGA. Entonces, de esta manera, puede construir su componente a partir de su colección de módulos y agregar algo de lógica de pegamento y algunos FSM. Para probar este componente, también deberá escribir un nivel superior que utilice su componente.

Así que esta es una especie de estrategia de diseño de abajo hacia arriba o una combinación de ambas. Creo que hay un cambio en el estilo de diseño de arriba hacia abajo a más de abajo hacia arriba si acumulas más experiencia.

Además de su colección de módulos, también reunirá algún tipo de patrones de diseño y protocolos que demostraron en el pasado que son útiles para resolver un problema: el uso de una interfaz FIFO para pasar flujos de datos o algún tipo de protocolo de enlace para acoplar FSM. .

Los estudiantes a menudo tienden a comenzar a codificar sin ningún dibujo y la herida por VHDL se comporta en simulación y/o hardware de una manera diferente. Intento convencerlos de que dibujen esquemas RTL de alto nivel y, si necesitan, también RTL de bajo nivel. Esto tiene 3 ventajas:

  1. puedes transformar el RTL en código
  2. no escribirás código imposible de sintetizar
  3. puede verificar la salida de su herramienta contra su dibujo

Desafortunadamente, los diagramas esquemáticos y de tiempo para diseños HDL no están tan extendidos como los diagramas UML para sistemas de software complejos.