3

Sometimes we need to do some sequential processes with some conditions that comes from outside of Process. we can declare some controlling signals for this conditions, for example like this :

Architecture ...
 Signal C : std_logic;
begin
 Process(SomeInputs)
 begin
  C <= '1';
 end Process;

 Process(Clock)
  Variable Counter : Integer := 0;
 begin
  if (Clock'Event and Clock = '1') then
   if C = '1' then
    Counter := Counter + 1;

    if Counter = 10 then
     Counter := 0;
     C <= '0';
    end if;
   end if;  
  end if; 
 end Process;
end;

end ... ;

in this situation signal C is multi source and can not be synthesizable.

Another example is Reset Signal, when the reset comes from outside the process or outside the component we can not Invert it.

One approach is to make a state machine like this :

Process(Clock)
begin
 if (Clock'Event and Clock = '1') then
  case Current_State is
   when State_X =>
    Current_State <= State_Y;
   when State_Y =>
    if C = '1' then
     Current_State <= State_X;
    else
     Current_State <= State_Y;
    end if;
   ...
  end case;
 end if;
end Process;

Or another way to handle this situation is declaring temporary signals like this :

Architecture ...
 Signal MySignal, MyTempSignal : std_logic_vector(N downto 0);
begin

 Process(Clock)
  Variable Counter : Integer := 0;
 begin
  if (Clock'Event and Clock = '1') then
   if MySignal /= MyTempSignal then
    Counter := Counter + 1;

    if Counter = 10 then
     Counter := 0;
     MyTempSignal <= MySignal;
    end if;
   end if;  
  end if; 
 end Process;

end ...;

With temporary signals we can do some process when some signals are changed.

Another way is adding condition signals in the sensitivity list of the process, but when the process is sequential with clock, it`s hard to handle them.

The main problem is every signal must drive from 1 source ( in one process ) and the question is :

What is the best synthesizable way to handle this situation when we need some controlling signals like 'Reset' ?

Mahmoud_Mehri
  • 1,643
  • 2
  • 20
  • 38
  • In your first example, the `Process(SomeInputs)` block is already incorrect. It might work in simulation, but is not a proper synthesis construct. You might even infer a latch, which you definitely don't want. But I don't get your question. What you see as a problem is very normal in HDL. – JHBonarius Jul 31 '17 at 17:36
  • Possible duplicate of [VHDL: How to use CLK and RESET in process](https://stackoverflow.com/questions/9989913/vhdl-how-to-use-clk-and-reset-in-process) – JHBonarius Jul 31 '17 at 17:39

2 Answers2

3

To deal with multiple processes interacting with the same signal, I usually do as follows:

  • First, define the signal itself, as well as set and reset signals. E.g. sig, sig_reset and sig_set,
  • Then, define a process in charge of affecting the value to sig using the sig_set and sig_reset signals,
  • Finally, you can affect values to sig_set and sig_reset signals from different processes.

If multiple processes must do the same action (e.g. reset), just declare one signal per process then OR them or put them all in the condition.

Example:

architecture ar of comp is
  signal sig, sig_rst1, sig_rst2, sig_set : std_logic;
begin
  sig_management:process(clk)
  begin
    if rising_edge(clk) then
      if sig_rst1 = '1' OR sig_rst2 = '1' then
        sig <= '0';
      elsif sig_set = '1' then
        sig <= '1';
      end if;
    end if;
  end process;

  set_proc:process(clk)
  begin
    if rising_edge(clk) then
      sig_set <= '0';
      if (condition) then
        sig_set <= '1';
      end if;
    end if;
  end process;

  -- Do the same for sig_rst signals

end architecture;
Epok__
  • 51
  • 4
2

Processes are about responsibilities. A process is responsible to drive one or more outputs. If a process adheres to a reset signal, created by another source (e.g. button) then a process it not allowed to invert such a reset, because it's not its responsibility! The same goes for any other signal.

So let's say a reset is generated by another process and not by a hard wired button: In such a case you have to "ask" the driving process to deassert the reset signal.

So let's assume further both processes implement a state machine, in such a case we are now in the area of: How to implement handshaking protocols between state machines.

Typically, you have a:

  • strobe -> done/valid
    • input: single strobe
    • output: flag signal that operation is done and results are valid until new strobe is applied
  • strobe -> busy (is equal to not idle)
    • input: strobe signal
    • output: state describing if new strobes are accepted
  • strobe/finished
    • input: strobe signal
    • output: strobe signal
  • valid -> acknowledge
    • input: flag signal indicating valid input data
    • output: strobe signal indication input data was consumed
  • ...

There are many more protocols and names.

Paebbels
  • 15,573
  • 13
  • 70
  • 139