Reset from Port to internal components connection

Question

I have a Module consisting from another module. e.g.

entity Layer is
port (
CLK: IN std_logic; -- Clock
DIN: IN std_logic;
RST: IN std_logic -- Reset
); -- Data 
end Layer;

architecture Behavioral Layer is

component MVM
port (
CLK: IN std_logic; -- Clock
DIN: IN std_logic; -- Data 
RST: IN std_logic -- Reset
);
end component;

signal MVM_RST:            std_logic;
port MAP( DIN => DIN, CLK  => CLK, RST => MVM_RST);

process(CLK) is
begin 
 if rising_edge(CLK) then
    IF RST='1' then
        MVM_RST   <= '1';            
    ELSE
        MVM_RST   <= '0';
    END IF;
END IF;
END PROCESS;   
end Behavioral;

The logic behind this is I have several other modules connected to reset (not shown in this example) and want them to reset at different time steps but all at the beginning (i dont know if this is runable, because i wrote it only as a minimin example)

my module 'MVM' is something like

 IF RST='1' THEN
        MVM_RESULT <= '0'; 
      ELSE 
        MVM_RESULT <= DIN;
 END IF;

The In port of the top module (the layer) is getting new data every clock cycle except for the first one. The first clock cycle is reserved for a high impulse of the reset signal. It starts with clock 0 to get a 0->1 transition

When I am looking at my simulation, the module receives data from the 3th cycle (or?). but so I am loosing 2 cycles instead of 1 cycle

The problem behind this is the part

 if rising_edge(CLK) then
    IF RST='1' then
        MVM_RST   <= '1';            
    ELSE
        MVM_RST   <= '0';
     END IF;

As far as I understand, it means in the first cycle MVM_Res is seted to 1 (which is correct), at the second clock cycle is set to 0, this means for me it can receive data from the 3th cycle (or?)

How to avoid the delay of two cycles. I only want a maximum of 1 cycle delay. I also dont want to directly connect my top module-reset to the component-reset

Here is my testbench (I converted the values to std_logic instead std_logic_vectors to have a minimum example)

entity tb_Layer is
end tb_Layer;

architecture TEST of tb_Layer is

    component Layer is
        port(
          CLK,DIN, RST:      IN      std_logic; 
        );
    end component;
            signal CLK, DIN, RST:    std_logic; 
BEGIN          
 uut: Layer PORT MAP(
     CLK=> CLK, DIN => DIN, RST=> RST); 
    tb: process
        BEGIN
            CLK <= '0';
            RST <= '1';
            DIN <= '0';
            wait for 100ns;
            CLK <= '1';
            wait for 100ns;
            RST <= '0';
            CLK <= '0';
            DIN <= '1';
            wait for 100ns;
            CLK <= '1';
            wait for 100ns;
            CLK <= '0';
            DIN <= '0';
            wait for 100ns;
            CLK <= '1';
            wait for 100ns;
        END PROCESS;   
end TEST;

What the component sees: The problem is that the first edge it transmits the RST high. SO the component sees after half a cycle too late the Reset high. But because of this the component sees a half cycle the 'u' and so the issue occurs.

Your analysis seems correct to me. Are you aware that you have a synchronous reset? And that `rising_edge()` detects a transition from `'0'` to `'1'`, but not from `'U'` to `'1'`? So what is the specific question you like to ask? — the busybee, Dec 18 '22 at 16:15
yes, synchronous and 0 to 1 the specific question is how to avoid the delay of two cycles. I only want a maximum of 1 cycle delay — hajo, Dec 18 '22 at 16:57
Please [edit] your question and show us your test bench. Apparently it does not start with defined levels on the signals. -- Do we agree that you have just one avoidable cycle at the start of the simulation output? (Please do **not** answer in the comments. Add such important information by [edit]ing your question.) — the busybee, Dec 18 '22 at 17:34
Does this answer your question? [synchronous Reset doesnt work (VHDL) in Simulation, but why?](https://stackoverflow.com/questions/74731848/synchronous-reset-doesnt-work-vhdl-in-simulation-but-why) — the busybee, Dec 18 '22 at 18:28
Please re-read my answer to your former question, we had this issue already. — the busybee, Dec 18 '22 at 18:29
It is a bad idea to change DIN and CLK at the same Time to 1 in your Testbench, because then it is not clear, if the rising clock edge already will See the New value 1 of DIN. This depends on the delta cycles which Are needed on the datapath to the clocked Process. So it is always better to change data Signals only at the inactive (falling) clock edge. Try this, perhaps the unwanted cycle will disappear. — Matthias Schweikart, Dec 18 '22 at 19:26
Thank you the_busybee. I changed it but the simulation didnt change. Its another issue (compare: last time it was from a X to an 1, this time its X->0->1). — hajo, Dec 18 '22 at 19:57
Thank you Matthias Schweikart It doesnt solve my issue, but it is a good hint! — hajo, Dec 18 '22 at 20:02
Your entity/architecture pair Layer is missing a context clause, the architecture body declaration is missing the reserved word **of**. No where is there a declaration of MVM_RESULT as seen in two of the waveforms. Your results as seen in those waveform images can't be duplicated, you don't provide a [mcve]. A physical literal (e.g. 100 ns) is comprised of two lexical elements, an abstract literal and an identifier which are required by the standard to have an intervening separator. You're code isn't portable. VHDL has blocks, not modules an entity is an external block. See [ask]. — user16145658, Dec 19 '22 at 19:46
The issue is in process tb in architecture TEST of tb_Layer. A good practice is to have the clock and reset provided by separate processes. Note RST is '1' for 200 ns spanning two rising edges of CLK. Your problem narrative isn't clear. — user16145658, Dec 19 '22 at 19:53
Thank you user16145658 . I am using the word "module" not as a predefined VHDL-word. I am refering by "module" to the architecture of my system. https://www.techtarget.com/whatis/definition/module I see your point and I agree to use a common defined language to express a problem by related words — hajo, Dec 27 '22 at 14:48

the busybee · Answer 1 · 2022-12-19T08:01:10.887

You still have the same reason as in your other question, the synchronous reset. In that question, you left the stimulating signals undefined in the first clock cycle, and wondered why the result occurred one clock cycle later than you expected. The suggested change removed the first problem, but not your current issue.

BTW, the shown wave diagram does not match the code of the test bench. Therefore, I respond to the wave diagram, because it seems that this is you problem.

Again, the synchronous nature of the internally generated reset signal delays the reset of the component MVM by one cycle:

At the first rising edge of CLK the signal MVM_RST latches the 'U', as this is the value of RST.
At the second rising edge of CLK the signal MVM_RST latches the '1' of RST and resets MVM_RESULT to all zeroes.
At the third rising edge of CLK the signal MVM_RST latches the '0' of RST and let MVM_RESULT take the value of DIN.

If you had evaluated and simulated the shown test bench, it would go like this:

At the first rising edge of CLK the signal MVM_RST latches the '1' of RST and resets MVM_RESULT to all zeroes.
At the second rising edge of CLK the signal MVM_RST latches the '0' of RST and let MVM_RESULT take the value of DIN.

You might want to learn how to display waves of internal signals with your simulator. Then you can look at MVM_RST to see when it is active.

Thank you for the answer. Your explanation brought me to the solution a little step closer even when I paid attention to this issue. But it does not solve my problem. I want to explain why. First of all, this is my testbench. And this is might be unexpected, the waveform is fitting to the testbench! This is the reset of the component (!), not of the Testbench. The problem is that the first edge it transmits the RST high. But because of this the component sees a half cycle the 'u' and so the issue occurs. (I added a screenshot to make it clear) — hajo, Dec 19 '22 at 18:03
Your answer gave me a good hint to discover this. I added this information the the original question post. But I am really searching for an answer to this — hajo, Dec 19 '22 at 18:07

Reset from Port to internal components connection

1 Answers1