A primera vista, esperaría que el código fuente VHDL a continuación se comporte como un registro de desplazamiento. En eso q, con el tiempo seria
"UUUU0", "UUU00", "UU000", "U0000", "00000", ....
pero en cambio siempre es U
despué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.
Muestra este resultado interesante e inesperado durante la simulación tanto en ModelSim como en ActiveHDL. No he probado otros simuladores y me gustaría (en segundo lugar una explicación de la causa) saber si otros actúan de la misma manera.
Para responder correctamente a esta pregunta debes entender que:
&
.Lo que también he encontrado:
temp(0)<='0';
se mueve dentro del proceso, 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 únicamente los resultados inesperados de la simulación. Los tipos de señales reales son solo una simplificación. Por esta razón, debe considerar sus respuestas con el código en el formulario tal como está.
Mi conjetura es que el optimizador del motor de simulación VHDL por error (o tal vez según la especificación) no se molesta en ejecutar las expresiones dentro del ciclo ya que no hay señales externas que cambien, aunque puedo refutar esto colocando el ciclo sin envolver en un ciclo.
Así que espero que la respuesta a esta pregunta tenga más que ver con los estándares para la simulación VHDL de sintaxis VHDL inexplí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;
Tiene que ver con lo que se puede evaluar fácilmente en el momento de la elaboración, formalmente, lo que se denomina una "expresión localmente estática". Esta es una regla de aspecto oscuro, pero merece un poco de reflexión; eventualmente tiene sentido, y su simulador es bastante correcto al alertarlo generando resultados no obvios.
Ahora, temp(1)
puede evaluarse en tiempo de compilación (incluso antes del 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 fueran funciones lower(foo) to upper(bar)
en un paquete declarado en otro lugar... ahora lo máximo que puede decir con certeza es que temp
está controlado, por lo que la expresión "localmente estática" es temp
.
Y eso significa que el proceso está limitado por estas reglas para controlar todo temp
, momento en el que tiene varios controladores activados temp(0)
: el proceso de control (sin valor inicial, es decir, 'u') y el externo temp(0) <= '0';
. Entonces, naturalmente, los dos controladores se resuelven en 'U'.
La alternativa sería una "pequeña regla hacky" (opinión) de que si los límites del bucle fueran constantes, haga una cosa, pero si se declararan como otra cosa, haga otra cosa, y así sucesivamente... hay, cuanto más complejo se vuelve el lenguaje... en mi opinión, no es una mejor solución.
temp(0)<='Z'
dentro del proceso 'arregla' el comportamiento (si arreglar es la palabra correcta), tal vez debería ser una máscara o un engaño...
Mate
david tweed
temp(0)
porque no hay "eventos" asociados con la constante literal. Poner la asignación dentroprocess
crea una asociación con los eventos del reloj que hace que funcione. Me pregunto si agregar unaafter
cláusula a la tarea sería una posible solución.