simple code, pls help

splee splee wrote:
> The compiler warns me that 'b' should be in
> the sensitivity list. Why is this so?
Why do you do 'a' in the sensitivity list?

> The compiler warns me that 'b' should be in
> the sensitivity list. Why is this so?
1. Because otherwise the simulation is wrong. In this code the output 
takes over the last value of b on a change of the input a, but
2. that doesn't represent the actual hardware implemented by the 
synthesizer. Actually theres only a dirct connection from input a to 
output c


> What will be RTL schematic circuit be in this case?

1

2

     a        a->b->c         c

3

    <Input>---<Alias>---<Output>

BTW: is this homework? Both of the questions are easily answered by 
playing with the simulator and the synthesizer...

Hi Miller,
I don't understand why it is a direct connection from input a to output 
c. Please see my argument, and see if it is wrong:

- when a changes, the entire process statement is evaluated. b is 
schedule to get the new value of a, c is scheduled to get the current 
value of b
- when process suspends, b is equal to a, both have the new value. And c 
is equal to previous value of b.
- c will not be equal to b (or a) because the process statement is only 
evaluated once (since b is not in the sensitivity list)
- so a to b is a direct connection, whereas from b to c is something 
else.

..? Not sure if my argument is valid. Please comment.

The compiler (synthesis toll) does ignore the sensitivity list!
The process is "running" all the time.

splee splee wrote:
> ..? Not sure if my argument is valid. Please comment.
Try it yourself. Have a look at the RTL schematics.

And as already stated:
The sensitivity list is only used by the simulation.
The synthesizer "adds" all of the missing singals to the list on its 
own. The synthesizer just generates an info, that some signals are 
missing.

Two questions here:
1. So the two codes below essentially are identical to each other 
(synthesized circuit)?

1

architecture Behav1 of simpleBuffer is

2

signal b    : STD_LOGIC;

3

begin

4

    process (a,b)

5

    begin

6

            b <= a;

7

            c <= b;

8

    end process;

9

end Behavioral;

1

architecture Behav2 of simpleBuffer is

2

signal b    : STD_LOGIC;

3

begin

4

            b <= a;

5

            c <= b;

6

end Behavioral;

2. In a process statement, a signal only gets its assigned value after 
the process suspends, eg. in Behav1, b only gets the value of a after 
the process suspends.
Why would a synthesis tool make it such complicated? I mean, why can't a 
signal get the value immediately, just like variable and like in C 
program?
What's the point of making things difficult?

splee splee wrote:
> Two questions here:
> 1. So the two codes below essentially are identical to each other
> (synthesized circuit)?
They are exactly the same.
Additionally this results in exactly the same hardware (just wiring...)

1

architecture Behav1 of simpleBuffer is

2

signal b    : STD_LOGIC;

3

begin

4

    process (a)

5

    begin

6

            b <= a;

7

    end process;   

8

9

    process (b)

10

    begin

11

            c <= b;

12

    end process;

13

end Behavioral;

And also this:

1

    process (a,b)

2

    begin

3

            b <= a;

4

            c <= b;

5

    end process;

is the same like this:

1

    process (a,b)

2

    begin

3

            c <= b;  

4

            b <= a;

5

    end process;

> 2. In a process statement, a signal only gets its assigned value after
> the process suspends, eg. in Behav1, b only gets the value of a after
> the process suspends.
> Why would a synthesis tool make it such complicated?
Because thats the behaviour defined in the language description of VHDL.

> I mean, why can't a signal get the value immediately,
> just like variable and like in C program?
If you use signals and a clock you can be sure: theres no need to 
observe the order of the instructions, because throughout the whole 
process the signal doesn't change its value. So this:

1

 signal a,b,clk : ...

2

  :

3

  process (clk) begin

4

    if rising_edge(clk) then

5

      b <= b+1;

6

      if (b=4) then

7

         a <= a+1;

8

      end if;

9

    end if;

10

  end process;

is exactly the same like this:

1

 signal a,b,clk : ...

2

  :

3

  process (clk) begin

4

    if rising_edge(clk) then

5

      if (b=4) then

6

         a <= a+1;

7

      end if;

8

      b <= b+1;

9

    end if;

10

  end process;

With variables you must be aware, where to add statements.

> What's the point of making things difficult?
Its not difficult, its just different... ;-)

Dear Miller,
But I thought within a process statement, all the expressions must be 
read sequentially, so is it just contradicting to what you mentioned 
that the following are the same? Otherwise I could just read them upside 
down?

1

  process (clk) begin

2

    if rising_edge(clk) then

3

      if (b=4) then

4

         a <= a+1;

5

      end if;

6

      b <= b+1;

7

    end if;

8

  end process;

1

  process (clk) begin

2

    if rising_edge(clk) then

3

      b <= b+1;

4

      if (b=4) then

5

         a <= a+1;

6

      end if;

7

    end if;

8

  end process;

> But I thought within a process statement, all the expressions must be
> read sequentially
Yes, thats right, but every signal keeps its old value throughout 
the whole process. The new values calculated in the process are 
assigned to the signal after finishing the process. So also this is the 
same as the descriptions above:

1

  process (clk) begin

2

    if rising_edge(clk) then

3

      b <= b+1;

4

      if (b=4) then

5

         a <= a+1;

6

         b <= b+1;

7

      end if;

8

      b <= b+1;

9

    end if;

10

  end process;

All of the processes above read essentially like this:

1

  process (clk) 

2

  variable temp_b;

3

  begin

4

    if rising_edge(clk) then

5

      new_b := b+1;          -- calc a new value based on the old value

6

      if (b=4) then          -- takt the old vale for the compare

7

         a <= a+1;

8

         new_b := b+1;       -- calc a new value based on the old value

9

      end if;

10

      new_b := b+1;          -- calc a new value based on the old value

11

    end if;

12

    b <= new_b;

13

  end process;

A new b is calcutlated, but for all of the calculations the old b is 
taken as a basis.

> Otherwise I could just read them upside down?
If only signals are involved: Yes.