Access to Next-Value of Clocked-Value, Without Needin Clocked and Unclocked Processes

Greetings Tricky, and All, as well:

My apology for not being clear enough. I'll try being more specific this time...

This more of a VHDL coding preference issue for code optimizing, as I know the logic result is available for the designed hardware result, however a single change of the design dramatically changes what is required for the code modification. Or, for instance, a state machine requires, as shown in almost every demonstrations, a clocked process and an unclocked process. This requires having 2 places which need to be identical format, and the desired sequence is controlled in 2 separate places, which makes not-so-readable.

Example code snippet, a counter used as a ROM address, with a flag for specific sectors:

...
signal count_en : std_logic;
signal counter : integer range 0 to 255;
signal mem : mem_t := init_mem_values;-- <= not defined for this code demo
signal mem_q : integer range 0 to 255;
signal segment_flag : integer range 0 to 3;--used to demonstrate a clocked result
...
begin
Process(reset, clock)
begin
if reset = '0' then
counter <= 0;
segment_flag <= 0;
elsif rising_edge(clock) then
    if count_en = '1' then
        counter <= counter + 1;
    end if;
    if counter < 10 then
        segment_flag <= 0;
    elsif counter < 29 then
        segment_flag <= 1;
    elsif ...
    end if;
end if;
end process;
process(clock)
begin
if rising_edge(clock) then
    mem_q <= mem(counter);
end if;
end process;
...

This has the counter used as the mem address and advances if the count_en is used, and it sends the segment_flag showing the mem_q position, as specified. The mem_q is one clock behind.

Now lets desire to have the mem_q is advanced 1 clock sooner, so it will match the count...

...
signal count_en : std_logic;
signal counter : integer range 0 to 255;
signal next_counter : integer range 0 to 255;
signal mem : mem_t := init_mem_values;-- <= not defined for this code demo
signal mem_q : integer range 0 to 255;
signal segment_flag : integer range 0 to 3;--used to demonstrate a clocked result
...
begin
--unclocked
Process(counter)
begin
next_counter <= 0;
--default
next_counter <= counter;
if count_en = '1' then
    next_counter <= counter + 1;
end if;
end process;
--clocked
Process(reset, clock)
begin
if reset = '0' then
counter <= 0;
mem_flag <= 0;
elsif rising_edge(clock) then
    counter <= next_counter;
    if next_count < 10 then
        segment_flag <= 0;
    elsif next_count < 29 then
        segment_flag <= 1;
    elsif ...
    end if;
end if;
end process;
process(clock)
begin
if rising_edge(clock) then
    mem_q <= mem(next_counter);
end if;
end process;
...

This hasn't been compiled, ignore any mistakes unless they creates confusion.

Here, a simple change to the design makes a dramatic change to organization, and divides the sequence into two separate processed. This could be much more complicated using many separate counters, with many enables to advance them, or a state-machine with many states used.

Hardware wise, the change routes the counter's 'D' input to the mem address, rather than the counter's 'Q' output to the mem address. This also does the same for the segment_flag to keep it synced with the mem output.

Hypothetically, if there was a VHDL attribute such as counter'next_clk to read the 'D' value as mentioned, to make the change, the attribute would be required in the mem_q(this spot), as well the if-else portion controlling the segment_flag. It wouldn't require doubling signals used, adding an unclocked process, and separating part to each process.

I frequently code a project using a single clocked process, until I find one specific issue where I need access the 'D' value to advance a clock value, and the only option I found so far is as shown. And using state machines, I know this in advance, and it's a pain having to generate the sequence in 2 separate places, not in a single sequential place.

In Quartus's RTL Viewer, every signal to a register's 'D' port is identified, such as 'counter~18' (more complicated if resets to not all '0') when the counter is only in a single clocked process. That is completely definable based on the entered VHDL code, so I would like to be able access the 'D' value with such as an attribute representing next clocked value, so I can organize my code better, and not have to duplicate processes and many signals.

I hopes this an interesting ides.

David K.