Relación entre los módulos RTL y Verilog

Estoy tomando un curso de diseño digital y no obtuve algo. El diseño RTL incluye la ruta de datos y el controlador, está bien, pero ¿cuál es la relación entre estos y los módulos verilog? Por ejemplo, ¿el controlador es un módulo en verilog? En general, ¿cómo se puede codificar RTL en verilog?

(Algunos) módulos de Verilog están implementando RTL...
RTL es lógica de transferencia de registro. Verilog y VHDL son los principales lenguajes para mejorar RTL, pero hay muchos otros. Verilog y VHDL también hacen otras cosas además de RTL.
Hmm... Supongamos que quiero diseñar un sistema en Basys3. Los leds aleatorios parpadearán secuencialmente y el usuario intentará repetir esta secuencia. La puntuación del usuario se incrementará por cada respuesta correcta. ¿Cómo puedo implementar dicho sistema? ¿Debería intentar diseñar un sistema de ruta de datos del controlador o módulos Verilog? Estoy muy confundido.
Parece haber aquí un malentendido fundamental de los conceptos.
si, creo que si
Entonces, ¿desde dónde debo comenzar a diseñar para el problema anterior?

Respuestas (2)

En primer lugar, Verilog es un lenguaje de descripción de hardware que se utiliza para describir una colección de hardware digital y es modulesolo una forma de encapsular jerárquicamente su descripción. Cada modulelímite puede ser físico, como los pines de un FPGA o IC, o una placa de circuito impreso, o puede ser lógico, como una ruta de datos o un controlador. En cualquier caso, un Verilog modulerepresenta algún componente funcional de su diseño que va desde una simple andpuerta (o más pequeña) invisible a simple vista, hasta un sistema tan grande como una habitación (o más grande). Pero, en general, el contenido de un módulo ocupa cierta cantidad de espacio físico, así como cierta cantidad de consumo de energía, calor, etc.

El contenido de un módulo puede ser una colección de otras instancias de módulos o una descripción escrita en muchos niveles de abstracción diferentes, de los cuales RTL es solo uno de los muchos niveles posibles. RTL, o nivel de transferencia de registro, es un código que se puede sintetizar fácilmente a partir de lo que parece un programa de procedimiento en hardware digital.

Uno de los problemas con muchos cursos es que, debido a la presión del tiempo, intentan enseñar conceptos con problemas que son demasiado pequeños para necesitar esos conceptos.

Un diseño es básicamente una jerarquía de módulos. En síntesis, su módulo de nivel superior generalmente describe "todo en el chip"; los submódulos luego describen partes del diseño. En la simulación, su módulo de nivel superior suele ser su código de banco de pruebas y luego el código que desea probar se instancia como un submódulo.

Hay varias ventajas de dividir un diseño en módulos.

  • Puede agrupar código lógicamente relacionado.
  • Las herramientas de síntesis generalmente presentarán el uso de recursos por módulo. Si no divide su diseño en módulos, no podrá saber qué parte de su código está utilizando todos los recursos.
  • Puede encapsular detalles locales, las señales son locales para un módulo a menos que las enrute explícitamente hacia adentro y hacia afuera.
  • Puede permitir la reutilización de bloques de código.

Sin embargo, también hay desventajas.

  • El enrutamiento de señales dentro y fuera de un módulo requiere el cableado de más código repetitivo.
  • Demasiados niveles de abstracción pueden hacer que sea difícil ver lo que está pasando.

El diseño RTL incluye ruta de datos y controlador, está bien

RTL significa que describimos lo que le sucede a cada registro en cada ciclo de reloj utilizando un subconjunto del lenguaje que las herramientas de síntesis saben cómo manejar.

La herramienta en su mayoría * no sabe ni le importa si un registro determinado es "ruta de datos" o "control", solo que define lo que le sucede de una manera que lo entienda.

Por ejemplo, ¿el controlador es un módulo en verilog?

Depende completamente de usted, puede fusionar la ruta de datos y el controlador en un solo bloque siempre. Podría tener un bloque always para el controlador y luego construir su ruta de datos a partir de una combinación de declaraciones de asignación, bloques always y submódulos. Podría tener un submódulo para la ruta de datos pero no el controlador.

Cuál funciona mejor depende del problema, si el manejo de datos es simple, poner todo en un bloque siempre puede tener más sentido. Si el manejo de datos se vuelve más complejo, puede tener sentido sacarlo del bloque siempre y describirlo de una manera más estructural para controlar mejor el uso de recursos.

Personalmente, solo dividiría el controlador y la ruta de datos en módulos separados si tuviera una buena razón, tal vez sean muy grandes, tal vez quiera usar un controlador para controlar varias copias de la ruta de datos, algo así.

Hmm... Supongamos que quiero diseñar un sistema en Basys3. Los leds aleatorios parpadearán secuencialmente y el usuario intentará repetir esta secuencia. La puntuación del usuario se incrementará por cada respuesta correcta. ¿Cómo puedo implementar dicho sistema? ¿Debería intentar diseñar un sistema de ruta de datos del controlador o módulos Verilog? Estoy muy confundido.

Analicemos esto.

Primero necesitamos una fuente de números "aleatorios". Probablemente la mejor manera de hacer esto es tener un generador de números pseudoaleatorios que funcione continuamente. El momento en que el usuario presiona el botón de inicio, elige qué número "aleatorio" y, por lo tanto, qué patrón de LED obtiene el usuario.

Sugeriría hacer que el generador de números "aleatorios" sea su propio módulo para que pueda reutilizarse en otros proyectos. Probablemente algo así como un registro de desplazamiento de retroalimentación lineal sea adecuado.

Probablemente también necesite un botón antirrebote que tome las señales de los botones y convierta las pulsaciones desordenadas en una señal alta durante exactamente un ciclo de reloj. Esto se convertiría en un módulo para permitir instancias múltiples para los diferentes botones.

El código real del juego probablemente lo escribiría como un solo bloque siempre. Podría intentar dividirlo, pero en mi opinión, los gastos generales del apretón de manos entre las diferentes partes probablemente superarían las ganancias.

* Una excepción a esto son los registros de estado de la máquina de estado. Si sigue las expresiones idiomáticas estándar de la máquina de estado, la herramienta normalmente se traducirá de cualquier número de estado que haya utilizado en su programa a una codificación de estado elegida para la eficiencia de la síntesis (a menudo 1-hot).