¿RTL frente a HDL? Cual es la diferencia

¿Cuál es la principal diferencia entre RTL y HDL? Para ser honesto, lo busqué / lo busqué en Google, pero las personas están divididas en sus opiniones. Recuerdo que uno decía que HDL es el lenguaje informático utilizado para describir un circuito digital y, cuando es sintetizable, se considera RTL.

Respuestas (2)

HDL es el nombre general para todos los lenguajes de definición de hardware (Verilog, VHDL, etc.) de la misma manera que Orientado a objetos puede referirse a C++, Java, etc.

RTL, por otro lado, es una forma de describir un circuito.

Usted escribe su código de nivel RTL en un lenguaje HDL que luego se traduce (mediante herramientas de síntesis) a la descripción del nivel de puerta en el mismo lenguaje HDL o lo que sea que tome su dispositivo/proceso de destino.

Dejame darte un ejemplo. Aquí hay una línea de Verilog (HDL) que describe un mux en RTL:

assign mux_out = (sel) ? din_1 : din_0;

Su herramienta de síntesis puede tomar eso y convertirlo en un conjunto de puertas lógicas, o simplemente en una macro mux compatible con su dispositivo final. Por ejemplo, podría instanciar una macro mux

mux u3 (mux_out, din_1, din_0);

En ambos casos, puede alimentar las mismas entradas al bloque (RTL o nivel de puerta) y su salida debería ser la misma. De hecho, hay herramientas que comparan la salida de su síntesis con su código RTL para asegurarse de que la herramienta no optimizó o cambió accidentalmente algo durante la síntesis que causó una falta de coincidencia. Esto se llama verificación formal.

Por una variedad de razones, interoperabilidad, facilidad de cambio, comprensibilidad, escribe su descripción del circuito digital como RTL, en lugar de nivel de puerta.

Buena respuesta, solo un refinamiento adicional ... RTL asume un estilo de diseño dado: nube lógica, registro, nube lógica, registro, etc., lo que implica un diseño síncrono (con reloj). SI estuviera codificando en su hdl para un diseño sin reloj (asincrónico), su herramienta de síntesis podría usar algo diferente a RTL.
De hecho, hay herramientas que comparan la salida de su síntesis con su código RTL para asegurarse de que la herramienta no optimizó o cambió accidentalmente algo durante la síntesis que causó una falta de coincidencia. Esto se llama Verificación Formal”. No, esto no lo es. Esto se llama verificación de equivalencia lógica o verificación de equivalencia formal. La verificación formal es más bien un proceso de prueba (usando métodos matemáticos, sin simulación/bancos de prueba) que la descripción de su hardware realmente describe el comportamiento que pretendía describir.

HDL (lenguaje de descripción de hardware) es el tipo de lenguaje utilizado, Verilog/VHDL frente a un javascript que no es HDL.

RTL (nivel de transferencia de registro) es un nivel de abstracción en el que está escribiendo. Los tres niveles a los que me refiero son Comportamiento, RTL, Nivel de puerta.

El comportamiento tiene la capa más alta de abstracción que describe el comportamiento general y, a menudo, no se puede sintetizar, pero es útil para la verificación.

RTL describe el hardware que desea implicando lógica. definiendo flip-flops, pestillos y cómo se transfieren los datos entre ellos. Esto es sintetizable, la síntesis puede alterar/optimizar la lógica utilizada pero no el comportamiento. Cambiando muxes para puertas, etc., algunas veces invirtiendo señales para optimizar mejor el diseño.

Verilog RTL que implica un flip-flop:

logic a;              //logic is SystemVerilog, could be a 'reg'
logic k;              // Driven by RTL not shown
always @(posedge clk or negede rst_n) begin
  if (~rst_n) begin
    a <= 'b0 ;
  end
  else begin
    a <= k ;
  end
end

Operadores combinatorios bit a bit:

logic [1:0] n;
logic [1:0] m;
logic [1:0] result;

assign result = n & m ;

El nivel de puerta es un diseño que utiliza las puertas lógicas básicas (NAND, NOR, AND, OR, MUX, FLIP-FLOP). No necesita ser sintetizado o es el resultado de la síntesis. Esto tiene el nivel más bajo de abstracción. son las puertas lógicas las que usará en el chip, pero carece de información posicional.

Nivel de puerta Verilog (misma función que arriba):

wire a;
wire k;
DFFRX1 dffrx1_i0 (
  .Q (a),   //Output
  .QN( ),   //Inverted output not used
  .D (k),   //Input
  .CK(clk), //Clk
  .RN(rst_n)// Active Low Async Reset
);

Combinacional

wire [1:0] n;
wire [1:0] m;
wire [1:0] result;

AND2X1 and2x1_i0 (
  .Y( result[0]),
  .A( n[0]     ),
  .B( m[0]     )
);
AND2X1 and2x1_i1 (
  .Y( result[1]),
  .A( n[1]     ),
  .B( m[1]     )
);
Si uno tuviera que diseñar un circuito como MyReg[7..1] := MyReg[6..0]; MyReg[0] := SerInput; MyReg.Clk = SerClk; MyReg[7..0].AR = !InBus[7..0] & Load; MyReg[7..0].AP = InBus[7..0] & Load;(un registro de desplazamiento de carga paralela asíncrono que podría implementarse en un CPLD Xilinx 9536 usando bloques con reinicio/preajuste asíncrono) ¿se consideraría RTL o nivel de puerta?
RTL, el nivel de la puerta se vería como AND(.a(),.b()) OR(.a(),.b())puertas puramente lógicas conectadas. Tengo la impresión de que RTL es cualquier cosa que pretenda sintetizar, incluso circuitos combinatorios, ya que todavía está describiendo el cambio en los datos, pero no las puertas lógicas directamente.
Incluyó "flip-flop" en su lista de puertas lógicas básicas; dado que son primitivos en algunas topologías, pensé que podría ser intencional. Escribir una especificación de comportamiento para cosas que combinan comportamiento asíncrono y síncrono parece más difícil que especificar el comportamiento en términos de entradas de flip flop, relojes, pines asíncronos preestablecidos y asíncronos.
Lo siento, no te sigo, intentaré aclararlo. RTL implica un flip-flop. Gate-level instancia un flip-flop. Para circuitos simples, conectar un montón de puertas lógicas puede ser simple. pero puede no ser eficiente en el área de potencia. Un procesador Atom tiene 47 millones de transistores, lo que equivale a alrededor de 10 millones de NAND2. ¿Le gustaría definir y depurar 10 millones de puertas cableadas a mano? Esta es la ventaja de abstraer un poco, podemos estudiar y depurar el comportamiento previsto.
Ciertamente, para partes de un circuito, las descripciones de alto nivel son útiles. Por otro lado, parecería que tratar de especificar el comportamiento de un flip flop con entradas asincrónicas set/clear sería más complicado y menos intuitivo que simplemente decir "use uno". Tal vez una descripción más detallada del comportamiento sería útil en el hardware que no tiene una primitiva de este tipo, ya que hay diferentes maneras en las que uno podría tratar de imitar la primitiva en el hardware que carece de ella; los métodos tienen diferentes costos y comportamientos ligeramente diferentes.
Supongamos que uno estuviera tratando de especificar un 74HC74 en un HDL. Hay una variedad de formas en que uno podría sintetizar un dispositivo de este tipo usando una combinación de lógica combinatoria, fracasos de solo sincronización y pestillos transparentes, pero no puedo imaginar ninguna implementación que no involucre condiciones de carrera o cree anomalías de comportamiento que no existe con primitivas de hardware (por ejemplo, si D y Q son altos, un pulso runt en CP o /SD no debería tener efecto, pero en las implementaciones puedo imaginar que tales pulsos podrían causar metaestabilidad y/o un fallo de salida).
@supercat No me he encontrado con 74HC74 antes de asumir que estamos hablando de un flip-flop Dual (2 bits), Set, Reset, posedge clk. ¿Qué parte te preocupa? establecer reinicio? o el doble? De los diagramas que he visto, el dual es solo dos chanclas de 1 bit. Si es el set-reset, puede estar implícito en rtl y la primitiva flip-flop set-reset se usaría en la síntesis. ¿O te he perdido el punto?
Si uno está utilizando hardware cuyas chanclas no tienen capacidad de configuración/reinicio asíncrono, es posible sintetizar dicho comportamiento, pero no conozco ninguna forma de sintetizar dicho comportamiento sin explotar las condiciones de carrera, que responderá correctamente a todos legítimamente- condiciones de entrada cronometradas que deberían hacer que cambie de estado, e ignorarán (sin fallas de salida ni metaestabilidad) las transiciones de entrada, independientemente del tiempo, lo que sin ambigüedades no debería hacer que cambie de estado [por ejemplo, pulsos de reloj cronometrados ilegítimamente en momentos en que D coincide con Q ]
Por ejemplo, si uno tuviera fracasos con reinicio asíncrono pero no asíncrono establecido, uno podría usar un fracaso para capturar el estado de D, alguna lógica para capturar si "establecer" o "borrar" fue activado en último lugar, un fracaso para indicar si "establecer " y/o "borrar" se han activado desde el último pulso de reloj, y un multiplexor para seleccionar el pestillo D o el pestillo establecer/borrar. Tal enfoque funcionaría correctamente en el estado estable, pero podría tener problemas de salida al cambiar entre informar datos de D-flop o RS-latch. La lógica de prevención de peligros en la salida puede ayudar, pero no sé si solucionaría todo.
Creo que estamos hablando del aspecto de portabilidad de código de RTL, pero si está tratando de implicar un cambio de configuración cuando su biblioteca base no tiene uno y ESPERA que la herramienta de síntesis pueda crear uno mágico, entonces sí eso conducirá a los problemas Espero que la herramienta de síntesis emita una advertencia al respecto. Lo que RTL le brinda es la capacidad de cambiar la resíntesis de bibliotecas/Foundries y obtener el mismo diseño funcional.
En realidad, es bastante raro para mí encontrar tales requisitos. Algunas interfaces de baja latencia y baja velocidad de reloj requieren uno o dos reinicios, pero nunca he usado más, los otros dos miles son D-Type normales.
Volviendo a mi pregunta original, si parte del dispositivo de uno necesita comportarse como un fracaso con el ajuste/reinicio asíncrono (por ejemplo, porque interactúa con cosas en el mundo exterior que esperan tal comportamiento), especificaría las cosas en términos de "MyLatch.D obtiene esto; MyLatch.clk obtiene esto; MyLatch.AR obtiene esto; etc." ser considerada una especificación de nivel de puerta o de nivel de transferencia de registro? Además, desde el punto de vista del comportamiento, ¿hay alguna forma de especificar en qué condiciones se permite que las salidas de un circuito fallen y en qué condiciones deben permanecer estables?
¿Cómo está creando MyLatchuna celda base instanciada o un pestillo implícito? Si crea una instancia de la puerta, es el nivel de la puerta. Si lo implica, es RTL. La biblioteca de nivel de puerta tendrá temporización asociada para modelar condiciones de carrera/fallas, etc. Las simulaciones RTL se ejecutan con componentes ideales.