0
\$\begingroup\$

In my VHDL design, I have a counter, and a reset mechanism. The counter counts up to 50M, and sets the "ready" signal to '1' and starts over. The reset signal is active high and resets the "ready" signal to '0' on a rising clock edge. Following is the VHDL code,

rst_pr : process(clk)
begin
if(rising_edge(clk)) then
    if(reset = '1') then
        ready <= '0';
    end if;
end if;
end process;

cntr : process(clk)
begin
    if(rising_edge(clk)) then
        if(counter = 50e6) then
            ready <='1';
            counter <= 0;
        else
            counter <= counter + 1;
        end if;
    end if;
end process;

"ready" is a std_logic type signal. "counter" is an integer type signal. I also realize that "ready" signal can be multidriven at some point, i.e. the logic is broken. Following is the simulation code, also very simple (vivado)

rst_pr : process
begin
reset <='1';
wait for 50ns;
reset <='0';
wait;
end process;

clkpr : process
begin
    clk <='1';
    wait for 5ns;
    clk <= '0';
    wait for 5ns;
end process;

Simulation shows "ready" is in the 'U' state all the time. This makes no sense, as at the beginning it is set to '0' by the reset process. I didn't share the entire code(entities,signal, library definitions etc.) to keep the post concise. Let me know if you want to see it.

Why does the simulator show "ready" as uninitialized?

\$\endgroup\$
  • 4
    \$\begingroup\$ If you know that the logic for ready is broken (multiple drivers) why don't you fix it and try again? Another hint: what is the value of counter at the instant when you turn on the power? \$\endgroup\$ – Elliot Alderson Aug 21 at 12:39
  • \$\begingroup\$ I am going to fix the logic. But still, it feels like the signal should be initialized. It could at some point become undefined but that doesn't explain why it is unitialized. \$\endgroup\$ – zeke Aug 21 at 12:43
  • 3
    \$\begingroup\$ Your "feels" are really of no value here. Fix the code. \$\endgroup\$ – Elliot Alderson Aug 21 at 13:08
  • \$\begingroup\$ Could the development tool be smart enough to realize the broken nature of the ready signal and thus declare it undefined as a result? You may also want to consider that the counter wants to be reset to zero at the reset time. \$\endgroup\$ – Michael Karas Aug 21 at 13:09
3
\$\begingroup\$

You never initialized counter, so the simulator can't tell whether or not ready is being driven in the cntr process. This U state overrides the drive from the rst_pr process.

Note that this is a problem only in the simulator. IRL (in real life), the counter will always have a definite value, even if you don't know what it is, and therefore, you'll know whether ready is being driven or not.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.