Counter status flags don't stay asserted not sure why?

To all,

I have a counter that uses a control input that toggles which signal I am incrementing. Both count values are restricted to a range and so they always stay in this range and wrap around when they go to the end of the range. I have some status flags called "full_status" and "empty_status" to which when the two addresses are equal - a situation when one of the pointers catches up to the other - the flags are asserted. This assertion is to stay active until the control signal "get_store_ctl" toggles to allow the other pointer to increment. Unfortunately the status flags given one state of the "get_store_ctl" is supposed to stay asserted when "get_addr = store_addr" until as I mentioned the "get_store_ctl" changes and the pointers themselves are not supposed to increment at all as I try to freeze this. This is not what happens, as the pointer itself keeps incrementing.

The section that is not functioning according to my description is the section in the VHDL code that has the IF statement that compares "updated_addr = comp_addr". Can someone correct the piece of VHDL code below? Again I'm expecting that once the flags are asserted according then the output address is always supposed to stay constant and not increment. This is what I would like to happen but for some reason it's not working this way.

LIBRARY ieee; USE ieee.std_logic_1164.ALL; USE ieee.std_logic_unsigned.ALL;

ENTITY free_memory_addr_counter IS GENERIC (NUM_OF_BITS : POSITIVE :=32); PORT( CLK :IN STD_LOGIC; RST_N :IN STD_LOGIC; PTR_EN :IN STD_LOGIC; GET_STORE_CTL :IN STD_LOGIC; EMPTY_FLAG :OUT STD_LOGIC; FULL_FLAG :OUT STD_LOGIC; GET_ADDR_PTR :OUT STD_LOGIC_VECTOR (NUM_OF_BITS-1 DOWNTO 0); STORE_ADDR_PTR :OUT STD_LOGIC_VECTOR (NUM_OF_BITS-1 DOWNTO

0); OUT_ADDR :OUT STD_LOGIC_VECTOR (NUM_OF_BITS-1 DOWNTO 0) ); END ENTITY free_memory_addr_counter;

ARCHITECTURE main_cntr_rtl OF free_memory_addr_counter IS

-- Define parameters signal full_status :std_logic; signal empty_status :std_logic; signal get_addr :std_logic_vector(NUM_OF_BITS-1 DOWNTO 0); signal store_addr :std_logic_vector (NUM_OF_BITS-1 DOWNTO 0); signal updated_addr :std_logic_vector (NUM_OF_BITS-1 DOWNTO 0); signal comp_addr :std_logic_vector (NUM_OF_BITS-1 DOWNTO 0);

constant START_MEM_ADDR :std_logic_vector(NUM_OF_BITS-1 DOWNTO 0) := x"01000000"; constant END_MEM_ADDR :std_logic_vector(NUM_OF_BITS-1 DOWNTO 0) := x"01000003"; --:= x"0100FFFF";

BEGIN

PROCESS (CLK, RST_N) BEGIN IF (RST_N = '0') THEN get_addr

Reply to
pinod01
Loading thread data ...

I didn't analyze your code in detail, but if you change a signal in a process, it will be not changed until the end of the process. Use variables, if you need some sequential order.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

What Frank said, but with some additional info:

Signal updates are postponed until the assigning process suspends, either at an explicit wait statement, or at the bottom of the process. Any signal assigned inside the clock-edge if/then clause in a clocked process infers a register. Any reference to that signal is a reference to the output of the inferred register, no matter when/where it occurs relative to any assignment.

Variables update immediately upon assigment. A variable reference infers storage (i.e. a register in a clocked process) if the variable is read before it is written in a given execution of the process, in which case it must "remember" the state from the previous execution. If a reference to a variable executes after an assignment to it, then that reference infers a combinatorial path instead of a registered one.

Andy

Reply to
Andy

To Andy & Frank,

I forgot some of the properties of the variable statement and appreciate the feedback. In fact this is exactly what I was trying to remember as this helped solve the problem. Thank you to both of you. I've managed to change the signal assignments to variables and also modified my reset condition so that one of the variable assignments starts at "start_address - 1" instead of "start_address". During the first clock cycle it seemed that the variable was updated right away and therefore caused my comparator to react and for the assertion of the status flags earlier than I wanted it.

Cheers P> Frank Buss wrote:

Reply to
pinod01

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.