¿Por qué este patrón VHDL simple para un registro de desplazamiento no funciona como se esperaba?


8

A primera vista, esperaría que el código fuente VHDL a continuación se comportara como un registro de desplazamiento. En ese q, con el tiempo sería

"UUUU0", "UUU00", "UU000", "U0000", "00000", ....

pero en su lugar siempre es Udespués de cinco (o más) ciclos de reloj consecutivos.

¿Por qué es esto?

Este código es en realidad una versión mucho más simplificada de una simulación mucho más complicada. Pero demuestra los síntomas que veo.

Exhibe este resultado interesante e inesperado durante la simulación tanto con ModelSim como con ActiveHDL, no he probado otros simuladores y (en segundo lugar, una explicación de la causa) me gustaría saber si otros actúan de la misma manera.

Para responder esta pregunta correctamente, debe comprender que:

  • Sé que esta no es la mejor manera de implementar un registro de desplazamiento
  • Sé que para la síntesis RTL esto debería tener un reinicio.
  • Sé que una matriz de std_logic es un std_logic_vector.
  • No conozco el operador de agregación, &.

Lo que también he encontrado:

  • Si la asignación temp(0)<='0';se mueve dentro del proceso, funciona.
  • Si el bucle se desenvuelve (ver código comentado), funciona.

Reitero que esta es una versión muy simplificada de un diseño mucho más complicado (para una CPU canalizada), configurada para mostrar puramente los resultados inesperados de la simulación. Los tipos de señal reales son solo una simplificación. Por esta razón, debe considerar sus respuestas con el código en el formulario tal como está.

Supongo que el optimizador del motor de simulación VHDL no se molesta por error (o tal vez según las especificaciones) en ejecutar las expresiones dentro del bucle ya que no hay señales fuera del cambio, aunque puedo refutar esto colocando el bucle sin envolver en un bucle.

Así que espero que la respuesta a esta pregunta tenga más que ver con los estándares para la simulación VHDL de la sintaxis VHDL no explícita y cómo los motores de simulación VHDL hacen sus optimizaciones, en lugar de si el ejemplo de código dado es la mejor manera de hacer algo o no.

Y ahora al código que estoy simulando:

 library ieee;
 use ieee.std_logic_1164.all;   

 entity test_simple is
    port (
        clk : in  std_logic;
        q   : out std_logic
    );                   
 end entity;

 architecture example of test_simple is
    type   t_temp is array(4 downto 0) of std_logic;
    signal temp : t_temp;
 begin

    temp(0) <= '0';

    p : process (clk)
    begin               
        if rising_edge(clk) then
            for i in 1 to 4 loop
                    temp(i) <= temp(i - 1);
            end loop;

            --temp(1) <= temp(0);   
            --temp(2) <= temp(1);
            --temp(3) <= temp(2);
            --temp(4) <= temp(3);
        end if;
    end process p;
    q <= temp(4);
 end architecture;

Y el banco de pruebas:

library ieee;
use ieee.std_logic_1164.all;

entity Bench is
end entity;

architecture tb of bench is

component test_simple is
    port (
        clk : in  std_logic;
        q   : out std_logic
    );                   
end component;

signal clk:std_logic:='0';
signal q:std_logic;     
signal rst:std_logic;

constant freq:real:=100.0e3;

begin                       
    clk<=not clk after 0.5 sec / freq;

    TB:process
    begin
        rst<='1';
        wait for 10 us;
        rst<='0';
        wait for 100 us;
        wait;
    end process;

     --Note: rst is not connected
    UUT:test_simple  port map (clk=>clk,q=>q) ;
end architecture;

primero intente inicializar temp en la declaración de señal, he encontrado que los simuladores de vhdl son extravagantes sobre dónde se inicializan las cosas
Matt

Parece que el simulador ignora la asignación concurrente temp(0)porque no hay "eventos" asociados con la constante literal. Poner la asignación dentro de processcrea una asociación con los eventos del reloj que hace que funcione. Me pregunto si agregar una aftercláusula a la asignación sería una posible solución alternativa.
Dave Tweed

Respuestas:


7

Tiene que ver con lo que puede evaluarse fácilmente en el momento de la elaboración, formalmente, lo que se llama una "expresión localmente estática". Esta es una regla de aspecto oscuro, pero merece cierta reflexión: eventualmente tiene sentido, y su simulador es bastante correcto al alertarlo al generar resultados no obvios.

Ahora, temp(1)puede evaluarse en tiempo de compilación (incluso antes que el tiempo de elaboración) y puede generar un controlador en el bit 1 de "temp".

Sin embargo, temp(i)implica un poco más de trabajo para las herramientas. Dada la naturaleza trivial de los límites del bucle aquí (1 a 4), es obvio para nosotros los humanos que temp (0) no se puede controlar y lo que está haciendo es seguro. Pero imagine que los límites eran funciones lower(foo) to upper(bar)en un paquete declarado en otro lugar ... ahora lo máximo que puede decir con certeza es que tempse maneja, por lo que la expresión "localmente estática" es temp.

Y eso significa que el proceso está limitado por estas reglas para conducir todo temp, en ese punto tiene múltiples controladores encendidos temp(0): la conducción del proceso (sin valor inicial, es decir, 'u') y el externo temp(0) <= '0';. Entonces, naturalmente, los dos controladores se resuelven a 'U'.

La alternativa sería una "pequeña regla hacky" (opinión) de que si los límites del bucle fueran constantes, hacer una cosa, pero si se declararan como algo diferente, hacer otra cosa, etc. hay, cuanto más complejo se vuelve el lenguaje ... en mi opinión, no es una mejor solución.


Buena respuesta (+1), pero no estoy de acuerdo con tu caracterización de "pequeña regla hacky". El objetivo de la simulación es representar el comportamiento del hardware real. Entiendo las restricciones creadas por la compilación independiente de módulos individuales, pero creo que la regla debería ser que cualquier cosa que pueda evaluarse en tiempo de compilación debería serlo. Esta sería una regla mucho más general y ayudaría al sistema a adherirse al principio de "menos sorpresa". Permitir que las herramientas no realicen esas evaluaciones me parece más "hacky".
Dave Tweed

Comentario justo: Ada, por ejemplo, tiene (y expresa formalmente) mucha más complejidad sobre reglas como esta, y logra presentar una vista mucho más simple para los usuarios (¡sin el factor WTF de C!). VHDL fue originalmente simplificado (IMO un poco demasiado lejos) de Ada. Pero quizás podría adoptar las reglas de "congelación de tipos" de Ada que permitirían este tipo de optimización cuando sea claramente seguro (como aquí) y lo prohibirían de otra manera ...
Brian Drummond

Gracias Brian, lo que dices ciertamente tiene sentido. La idea de una regla simple en lugar de muchas reglas oscuras parece tener sentido también. ¿Diría que este comportamiento es verdadero (y de hecho especificado) para todos los simuladores o son solo los dos que he probado?
Jason Morgan

2
Si encontrara uno que hiciera algo diferente, ¡presentaría un error contra él! Una cosa que los mayores detractores de VHDL dirán a su favor es que garantiza resultados de simulación consistentes en los casos en que otros idiomas (no solo Verilog) no lo hacen. (aunque sí, ¡a veces sus defectos también me molestan!)
Brian Drummond

1
Experimento de solución rápida: si mi respuesta es correcta, puede conducir "temp (0) <= 'Z';" dentro del proceso, por lo tanto, "desconectando" el controlador fantasma, y ​​el controlador externo funcionará ...
Brian Drummond
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.