procedure of PROCESS in VHDL

[kahroba92]

Hi friends,

I have a misunderstanding in VHDL concepts in process description.

I know that “process” is executed sequentially in VHDL. Consider this example:
If a=1, b=2 and c=3:

Process (clock)
begin
if rising_edge (clock) then
b <= a;
c <= b;
end if;
end process;

in above example, after a period of clock, b is 1 and the old value of b is assigned to c (i.e c = 2).
I cannot interpret this fact for myself that why is said process is sequentially but signals are updated at the end of process?

thanks for your answers.

 

[barry]

The statements assigning signals INSIDE a process are NOT sequential. (VARIABLES are a different story, but ignore them for now). If you drew a schematic of what the process actually represents it would make more sense. Think of it this way. There are 2 flip-flops, B and C.
The D input of B is A; the D input of C is the Q output of B. Thus, when the clock edge occurs both B and C are updated with the value of their D inputs PRIOR to the clock edge.

YOU MUST THINK OF THIS IN HARDWARE TERMS. THIS IS NOT SOFTWARE!!!!

 

[TrickyDicky]

The statements assigning signals INSIDE a process are NOT sequential.

All VHDL code is sequential. Your further statements are related to the mapping of VHDL to hardware, not about the VHDL itself. But yes, you really should imagine hardware when writing VHDL, not thinking like a software programmer.
Signals are only updated at the end of the current delta cycle (so when a process suspends). So the order in which assignments occur is important, as the last one will give the value to the signal. It is quite common nowadays that engineers will assign multiple values to a signal knowing that the last one will get taken. EG.

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
process(clk)
begin
  if rising_edge(clk) then
    some_sig <= '0';   -- default
 
    if some_condition_occurs then
      some_sig <= '1';
    end if;
  end if;
end process;

---

If the condition expression was done above the first assignmnt to '0', then some_sig would never become '1'

 

[barry]

All VHDL code is sequential

I beg to differ. The OP is assuming that each statement in the process is executed sequentially. They are not. Each statement in the process is executed SIMULTANEOUSLY at the clock edge (at the end of the process).

 

[KlausST]

Hi,

I agree with barry:

b <= a;
c <= b;

Both lines are executed simultaneously. They act as two D-FF with the same clock.

Klaus

 

[TrickyDicky]

As you'll see from my example, that cannot be the case, otherwise some_sig would have multiple drivers, as it is being driven to '0' and '1' in the same process, but it because of the fact that the code is sequential that it works.

Processes occur in parallel, but code within a process is sequential (from a simulation/execution pov). It may be synthesised into parallel circuits however.

 

[andre_luis]

Simply put, if there is any FF inferred then it is a sequential logic, otherwise it would be combinational, isn't it ?

 

[KlausST]

Hi,

example of post#3:

My personal taste: I don´t like this "software"-like programming style. (pre-definging a variable and later modfiy it .. this is OK with true software)
Here it really leads to the assumption that the lines are processed sequentially. Confusing people - especially newbies.
Indeed it´s the compiler that detects the situation and rectifies it.

I assume in this case it generates a single D-FF.

***
I rather like the (more obvious simultaneous acting) CASE command. Acting like a MUX.

Klaus

 

[barry]

Simply put, if there is any FF inferred then it is a sequential logic, otherwise it would be combinational, isn't it ?

You are confusing sequential with synchronous. (Maybe it's a language distinction.) The whole point is that the OP was questioning why each signal assignment within the process didn't occur sequentially. (Just wait until OP starts asking about variables.)

- - - Updated - - -

Forgetting about the situation of multiple signal assignments in a single process for now, the order of signal assignment statements in a process make no difference, i.e. they are NOT sequential.

Code:

b <= a;
c <= b;

and

Code:

c <= b;
b <= a;

perform the exact same function. There is no sequentiality.

 

[kahroba92]

The statements assigning signals INSIDE a process are NOT sequential. (VARIABLES are a different story, but ignore them for now). If you drew a schematic of what the process actually represents it would make more sense. Think of it this way. There are 2 flip-flops, B and C.
The D input of B is A; the D input of C is the Q output of B. Thus, when the clock edge occurs both B and C are updated with the value of their D inputs PRIOR to the clock edge.

YOU MUST THINK OF THIS IN HARDWARE TERMS. THIS IS NOT SOFTWARE!!!!

Assignments inside process are sequential.



This a shot of pedroni book. P 65.

 

[kahroba92]

As you'll see from my example, that cannot be the case, otherwise some_sig would have multiple drivers, as it is being driven to '0' and '1' in the same process, but it because of the fact that the code is sequential that it works.

Processes occur in parallel, but code within a process is sequential (from a simulation/execution pov). It may be synthesised into parallel circuits however.

I agree with you. code within a process is sequential.

Please consider my example again: (a=1, b=2 and c=3)

Process (clock)
begin
if rising_edge (clock) then
b <= a;
c <= b;
end if;
end process;

in risign edge of clock at zero time b DFF is 1 and c DFF is 2. This is right. But it’s not the sequential meaning.
In my perspective, sequential means that 1 is stored in b DFF and after that this 1 is assigned to c DFF.

Is my understanding about sequential meaning wrong?

 

[TrickyDicky]

If you look are respective clocks:

Time=0 a=1, b=2, c=3 (no clocks have occured yet)
Time=1 a=1, b=1, c=2 (first clock - this case holds until the next rising clock edge)
Time=2 a=1, b=1, c=1

This models the behaviour of hardware flip flops, and is consistant with the language. Signals only get assigned at the end of the current delta time cycle, so no matter the order of the signal assignments, it will follow the pattern above.

The process is only triggered when there is a change in the value of clock (ie. a 'event - this might be 0->1, 1->0, 'U' -> 'X' - any change) but the if rising_edge statement means it will only execute the assignments on a rising edge (0 -> 1 transition)

I don´t like this "software"-like programming style.

It is pretty much the advocated style for state machines since textbooks were first written:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
comb_proc : process(all) --because 2008
begin
  ns  <= state;  -- hold state
  op <= '0';  -- default state machine output
 
  case state is
    when state1 => 
      --I did defaults so I didnt have to write explicit assignments in my 100 states, and get copy/pasta fails
    
    if some_condition then
      ns <= special_state;
    end if;
   when special_state => 
    op <= 1;
 
  end case;
end process;

---

 

[kahroba92]

If you look are respective clocks:

Time=0 a=1, b=2, c=3 (no clocks have occured yet)
Time=1 a=1, b=1, c=2 (first clock - this case holds until the next rising clock edge)
Time=2 a=1, b=1, c=1

right.

in this way, is the highlighted line the result of sequential execution?

it seems concurrent execution!

 

[barry]

The problem here is mainly semantics. SYNCHRONOUS means that a circuit is controlled by a clock. SEQUENTIAL means that events happen in an order, but there is nothing requiring a clock. For example, a ripple counter where the Q output of one flip-flop drives the clock input of the next flip-flop is a SEQUENTIAL circuit. It is NOT a SYNCHRONOUS circuit.

 

[TrickyDicky]

right.

in this way, is the highlighted line the result of sequential execution?

it seems concurrent execution!

You need to understand how signals work. An assignment is not immediate. In code, a signal assignment schedules the signal to be updated when the process suspends. So all the signals are scheduled with their new values, then they are all updated. The scheduling is done in the order the code is written.

 

[vGoodtimes]

@kahrob92: the signal assignment doesn't actually assign immediately. You can imagine the line to mean: Evaluate the right hand side, add a transaction "the left hand side gets this evaluated value" to a queue. When the process ends (or wait is reached), resolve these transactions. When a signal is assigned to multiple times before the process ends (or reaches wait), the last reached assignment is used.

This is a semi-accurate, easy explanation.

In this case, the process is "sequential" because statements are reach from top to bottom. if a signal is assigned multiple times, the last reached assignment is used -- this means some ordering is known. For simulation, a testbench might use a process with multiple wait statements -- this makes it much more clear that the process is evaluated in a sequence. Even if assignments eventually occur in parallel.



In terms of assigning a signal multiple times in a process, there are three valid use cases. The first is to provide an initial value to a signal that is not "a <= a". The second (IMO) is to place the reset block at the end of a process, allowing resetable control and non-resetable data signals to be in the same process. The third is for priority encoders where a for-if loop is used. These are just my opinion. It cleans up the code quite a bit and is still easy to understand.

 

[barry]

For simulation, a testbench might use a process with multiple wait statements -- this makes it much more clear that the process is evaluated in a sequence. Even if assignments eventually occur in parallel.

This is not how it works. If you've got a wait statement, then you can't have a clock. Signals will get assigned at the end of the wait time. Not at the end of the process.

 

[vGoodtimes]

This is not how it works. If you've got a wait statement, then you can't have a clock. Signals will get assigned at the end of the wait time. Not at the end of the process.

I guess ignore this. I don't know how to describe the tech without confusing the original poster. And I suspect this is just a simple miscommunication that leads into pointless confusion on a side topic.

 

[TrickyDicky]

This is not how it works. If you've got a wait statement, then you can't have a clock. Signals will get assigned at the end of the wait time. Not at the end of the process.

They dont get assigned at the end of the wait time - they get assigned at the end of the current delta cycle (ie. when the process suspends). The wait statement just forces the process to wait for the specified time, but the signals will be assigned at the start of the wait period. A process with a sensitivity list suspends when it gets to the end of the process (waiting for the next 'event), a process with no sensitivity list suspends when it hits a wait statement.

Your comments all talk about VHDL as if it was only a synthesisable language. There are many aspects that are possible that are not synthesisable, and more that are uncommon but perfectly synthesisable. It is perfectly acceptable to have a wait statement in a process that is clocked - the following is perfectly synthesisable, and demonstrates that code in a process is sequential:

---

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
-- Infers a register in all synth tools
process
begin
  wait until rising_edge(clk);
  op <= ip;
end process;
 
-- should also synthesis and infer register
process
begin
  wait on clk;
  if rising_edge(clk) then
    op <= ip;
  end if;
end process;
 
--also infers a register
op <= ip when rising_edge(clk);

---

I have also seen code in the past (cannot find it now) that used multiple wait statements in a process and was synthesisable in several tools, and this was 5-10 years ago.

I am going over this because while we are all taught, and it is drilled into us, that VHDL MUST be written to some conforming template, the reality is that VHDL is just a language, and we have be writing the same accepted style for many years. The tools are getting better and it is worth knowing how the language works at a base level to get the most out of it.

To the OP: while this is quite a complicated discussion, you are better off learning digital logic first before trying to understand VHDL.

 

[dpaul]

To the OP.....

Keeping it simple!
1. All processes are executed in parallel.
2. Statements inside a process are executed sequentially.
3. There can be multiple assignments to a signal within a process and only the last assignment takes effect. And how this effect take splace is explained by Tricky in #15.