EmbDev.net

Forum: FPGA, VHDL & Verilog Divider for unsigned integers.


von Omar Rashad (Guest)


Rate this post
useful
not useful
Hello

I just got asked this programming question in an interview:

Programming Test:

Design a VHDL/Verilog module to divide two unsigned std_logic_vector 
numbers and floor the result.  For example, if I provided you a vectors 
of 0x9 and 0x2 as the dividend and divisor, the result would be 0x4. 
The input vectors can be considered valid as soon as the 'start' input 
is pulsed high and the result must be presented on the 'quotient' output 
along with asserting 'done' for one clock cycle.

Important: The design must synthesize on either Xilinx or Altera tools 
targeting a Spartan/Cyclone class FPGA with the most efficient resource 
utilization and as few clk cycles as you are able to achieve.  (Results 
are evaluated first on proper operation and ability to synthesize to 
hardware, second on optimization.)

The interface entity is provided below:

entity divider is
  port
  (
    clk      : in std_logic;
    start    : in std_logic;
    dividend : in std_logic_vector(7 downto 0);
    divisor  : in std_logic_vector(7 downto 0);
    done     : out std_logic;
    quotient : out std_logic_vector(7 downto 0)
  );
end entity divider;

This was my code:
1
 library ieee;
2
use ieee.std_logic_1164.all;
3
use ieee.numeric_std.all;
4
5
entity divider is 
6
  port 
7
  ( 
8
    clk      : in std_logic; 
9
    start    : in std_logic; 
10
    dividend : in std_logic_vector(7 downto 0); 
11
    divisor  : in std_logic_vector(7 downto 0); 
12
    done     : out std_logic; 
13
    quotient : out std_logic_vector(7 downto 0) 
14
  ); 
15
end entity divider;
16
17
architecture behavior of divider is
18
signal Qfinal, Qtemp, counter: std_logic_vector (7 downto 0):=(others=>'0');
19
type state_type is (s0, s1, s2);
20
signal state, n_state: state_type:=s0;
21
22
begin
23
Qtemp <= std_logic_vector(unsigned(divisor));
24
25
process (clk)
26
begin
27
  if (clk = '1' and clk'event) then
28
    state <= n_state;
29
  end if;
30
end process;
31
32
process (start, dividend, divisor, state)
33
begin
34
  case state is
35
    when s0 => if (start = '0') then
36
                 n_state <= s0;
37
               else
38
                 n_state <= s1;
39
               end if;
40
    when s1 => if (start = '0' or dividend'event or divisor'event) then
41
                 n_state <= s0;
42
               elsif (Qfinal = dividend) then
43
                 n_state <= s2;
44
               else
45
                 n_state <= s1; 
46
               end if;
47
    when s2 => n_state <= s2;
48
  end case;
49
end process;
50
51
process (state)
52
begin
53
  case state is
54
    when s0 => quotient <= (others => '0'); done <= '0';
55
    
56
    when s1 => if (Qtemp < dividend) then
57
                 Qtemp <= std_logic_vector(unsigned(Qtemp) + unsigned(divisor));
58
                 counter <= std_logic_vector(unsigned(counter)+1);
59
                 if (Qtemp > dividend) then
60
                   counter <= std_logic_vector(unsigned(counter)-1);   
61
                   Qfinal <= dividend;
62
                 end if;               
63
                 quotient <= counter; done <= '0';
64
               elsif (Qtemp = dividend) then
65
                 quotient <= counter; done <= '0'; Qfinal <= dividend;
66
               else
67
                 counter <= std_logic_vector(unsigned(counter)-1); done <= '0';
68
                 quotient <= counter; Qfinal <= dividend;
69
               end if;
70
    
71
    when s2 => quotient <= counter; done <= '1';
72
  end case;
73
end process;
74
end behavior;

However, upon simulating I get a constant quotient output as 0. I 
probably screwed this one up for the interview but I still want to learn 
how to do this. Can someone direct me as to why my code isn't 
functioning?

:
von Uwe B. (uwe_beis)


Rate this post
useful
not useful
Hi Omar,

I'm not a VHDL guru, and I did not study your code, but 3 things 
attracted my attention. Two of them are minor:

1. Omar Rashad wrote:
> with the most efficient resource
> utilization and as few clk cycles as you are able to achieve.

This is a contradictory requirement. You can achieve either a sequential 
solution with the most efficient resource utilization or fully static 
design with zero clk cycles.

2. Why do you so often assign std_logic_vectors to std_logic_vectors 
with an additional type conversion?

The last one is more irritating:

You have the concurrent statement
  Qtemp <= std_logic_vector(unsigned(divisor));

and later a sequential statement where you re-assign Qtemp:
  Qtemp <= std_logic_vector(unsigned(Qtemp) + unsigned(divisor));
That is contradictory and should lead to am error. But it seems you get 
no error?

Uwe

von Lothar M. (Company: Titel) (lkmiller) (Moderator)


Rate this post
useful
not useful
Omar Rashad wrote:
> signal Qfinal, Qtemp, counter: std_logic_vector (7 downto 0)
Why not simply using unsigned vectors for calculations? Thats what the 
numeric_std package is desingd for. You would have much less hazzle with 
casting types from here to there and backwards...

> with the most efficient resource utilization and as few clk cycles as
> you are able to achieve.
You can have either the one or the other. But usually a (slow) single 
clock cycle divider is NOT efficient in a way to use less real silicon.

> when s1 => if (start = '0' or dividend'event or divisor'event) then
Huh, Ouch, Whow!
You simply invoked an additional clock signal here (the 'event!!!). That 
will NEVER ever run on real hardware, but thats required: "The design 
must synthesize on Xilinx or Altera"...

Have a look there (maybe Google translator or Babelfish will help):
Beitrag "Division in VHDL"
http://www.lothar-miller.de/s9y/archives/29-Division-in-VHDL.html

And a funny gag: Altera will implement a combinatorial divider just by 
using the '/' operator. See in the 
Beitrag "Re: Rechnen mit unsigned vs. signed und einer division"

: Edited by Moderator
von Omar Rashad (Guest)


Rate this post
useful
not useful
Lothar Miller wrote:
> Omar Rashad wrote:
>> signal Qfinal, Qtemp, counter: std_logic_vector (7 downto 0)
> Why not simply using unsigned vectors for calculations? Thats what the
> numeric_std package is desingd for. You would have much less hazzle with
> casting types from here to there and backwards...

1. I don't exaty understand what you mean. Can you give me an example of 
how you would write these assignments then? Also, the reason I use these 
type conversions is that numeric_std requires that ou declare any vector 
as signed or unsigned before operating on it. Isn't that correcT?
2. Thanks for the note on Qtemp. I understand part of the confusion now. 
But I need to initialize Qtemp to the value of the divisor. How can I do 
that using signals and/or variables?

>> with the most efficient resource utilization and as few clk cycles as
>> you are able to achieve.
> You can have either the one or the other. But usually a (slow) single
> clock cycle divider is NOT efficient in a way to use less real silicon.
>
>> when s1 => if (start = '0' or dividend'event or divisor'event) then
> Huh, Ouch, Whow!
> You simply invoked an additional clock signal here (the 'event!!!). That
> will NEVER ever run on real hardware, but thats required: "The design
> must synthesize on Xilinx or Altera"...

Since my divider is sequential the input has to be maintained at its 
value until the output is calculated. So if the input changes before 
completion that should take us back to state s0. How else can I 
implement that?

> Have a look there (maybe Google translator or Babelfish will help):
> Beitrag "Division in VHDL"
> http://www.lothar-miller.de/s9y/archives/29-Divisi...
>
> And a funny gag: Altera will implement a combinatorial divider just by
> using the '/' operator. See in the
> Beitrag "Re: Rechnen mit unsigned vs. signed und einer division"

von Omar Rashad (Guest)


Rate this post
useful
not useful
Using the feedback I received so far, I have slightly changed the code 
to this:
1
library ieee;
2
use ieee.std_logic_1164.all;
3
use ieee.numeric_std.all;
4
5
entity divider is 
6
  port 
7
  ( 
8
    clk      : in std_logic; 
9
    start    : in std_logic; 
10
    dividend : in std_logic_vector(7 downto 0); 
11
    divisor  : in std_logic_vector(7 downto 0); 
12
    done     : out std_logic; 
13
    quotient : out std_logic_vector(7 downto 0) 
14
  ); 
15
end entity divider;
16
17
architecture behavior of divider is
18
signal Qtemp, Qfinal, counter: std_logic_vector (7 downto 0):=(others=>'0');
19
type state_type is (s0, s1, s2);
20
signal state, n_state: state_type:=s0;
21
22
begin
23
24
process (clk)
25
begin
26
  if (clk = '1' and clk'event) then
27
    state <= n_state;
28
  end if;
29
end process;
30
31
process (start, dividend, divisor, state)
32
begin
33
  case state is
34
    when s0 => if (start = '0') then
35
                 n_state <= s0;
36
               else
37
                 n_state <= s1;
38
               end if;
39
    when s1 => if (start = '0') then
40
                 n_state <= s0;
41
               elsif (Qfinal = dividend) then
42
                 n_state <= s2;
43
               else
44
                 n_state <= s1; 
45
               end if;
46
    when s2 => n_state <= s2;
47
  end case;
48
end process;
49
50
process (state)
51
begin
52
  case state is
53
    when s0 => quotient <= (others => '0'); done <= '0';
54
    
55
    when s1 => if (Qtemp < dividend) then
56
                 Qtemp <= std_logic_vector(unsigned(Qtemp) + unsigned(divisor));
57
                 counter <= std_logic_vector(unsigned(counter)+1);
58
                 if (Qtemp > dividend) then
59
                   counter <= std_logic_vector(unsigned(counter)-1);   
60
                   Qfinal <= dividend;
61
                 end if;               
62
                 quotient <= counter; done <= '0';
63
               elsif (Qtemp = dividend) then
64
                 quotient <= counter; done <= '0'; Qfinal <= dividend;
65
               else
66
                 counter <= std_logic_vector(unsigned(counter)-1); done <= '0';
67
                 quotient <= counter; Qfinal <= dividend;
68
               end if;
69
    
70
    when s2 => quotient <= counter; done <= '1';
71
  end case;
72
end process;
73
end behavior;

I still get the output as 0. The concurrent assignment was removed and 
so was the additional clock. Please help.

von Omar Rashad (Guest)


Rate this post
useful
not useful
After going through the code several times, I discovered some possible 
sources of the problem and corrected them (but the output is still 0). 
Anyway, I decided to keep them as they seemed to make sense.

1. I initialized only state to s0 and not n_state. I thought that might 
have been keeping the state = s0 infinitely.

2. I replaced Qfinal with a flag signal called complete since the only 
use of that signal was to really indicate completion of division.

3. I eliminated the last else conditional statements in the last process 
in the second block of the case statement as it was redundant.

This is the new code
1
library ieee;
2
use ieee.std_logic_1164.all;
3
use ieee.numeric_std.all;
4
5
entity divider is 
6
  port 
7
  ( 
8
    clk      : in std_logic; 
9
    start    : in std_logic; 
10
    dividend : in std_logic_vector(7 downto 0); 
11
    divisor  : in std_logic_vector(7 downto 0); 
12
    done     : out std_logic; 
13
    quotient : out std_logic_vector(7 downto 0) 
14
  ); 
15
end entity divider;
16
17
architecture behavior of divider is
18
signal Qtemp, counter: std_logic_vector (7 downto 0):=(others=>'0');
19
signal complete: std_logic := '0';
20
type state_type is (s0, s1, s2);
21
signal state: state_type := s0;
22
signal n_state: state_type;
23
24
begin
25
26
process (clk)
27
begin
28
  if (clk = '1' and clk'event) then
29
    state <= n_state;
30
  end if;
31
end process;
32
33
process (start, dividend, divisor, state)
34
begin
35
  case state is
36
    when s0 => if (start = '1') then
37
                 n_state <= s1;
38
               else
39
                 n_state <= s0;
40
               end if;
41
    when s1 => if (start = '0') then
42
                 n_state <= s0;
43
               elsif (complete = '1') then
44
                 n_state <= s2;
45
               else
46
                 n_state <= s1; 
47
               end if;
48
    when s2 => n_state <= s2;
49
  end case;
50
end process;
51
52
process (state)
53
begin
54
  case state is
55
    when s0 => quotient <= (others => '0'); done <= '0';
56
    
57
    when s1 => if (Qtemp < dividend) then
58
                 Qtemp <= std_logic_vector(unsigned(Qtemp) + unsigned(divisor));
59
                 counter <= std_logic_vector(unsigned(counter)+1);
60
                 if (Qtemp > dividend) then
61
                   counter <= std_logic_vector(unsigned(counter)-1);   
62
                   complete <= '1';
63
                 end if;               
64
                 quotient <= counter; done <= '0';
65
               else 
66
                 quotient <= counter; done <= '0'; complete <= '1';
67
               end if;
68
    
69
    when s2 => quotient <= counter; done <= '1';
70
  end case;
71
end process;
72
end behavior;

This is the test bench:
1
library ieee;
2
use ieee.std_logic_1164.all;
3
4
entity tb_divider is
5
end tb_divider;
6
7
architecture behavior of tb_divider is
8
  component divider
9
    port (  clk      : in std_logic; 
10
    start    : in std_logic; 
11
    dividend : in std_logic_vector(7 downto 0); 
12
    divisor  : in std_logic_vector(7 downto 0); 
13
    done     : out std_logic; 
14
    quotient : out std_logic_vector(7 downto 0) 
15
  ); 
16
  end component;
17
18
signal clk: std_logic:='0';
19
signal done, start: std_logic;
20
signal dividend, divisor, quotient: std_logic_vector (7 downto 0);
21
22
begin
23
clk <= not clk after 5 ns;
24
DUT: divider port map (clk, start, dividend, divisor, done, quotient);
25
26
process
27
begin
28
wait for 0 ns; start <= '1'; dividend <= "00001001"; divisor <= "00000100";
29
wait for 200 ns;
30
end process;
31
end behavior;

von Lothar M. (Company: Titel) (lkmiller) (Moderator)


Rate this post
useful
not useful
Omar Rashad wrote:
> (but the output is still 0).
You know, that you can dig inside a module with the simulator?
Usually you have to open the corresponding node on the structure tree on 
the left side. Then you can select signals from inside a module and drag 
them to the waveform window. There you can see whats going on after 
restarting the simulation.

von Achim S. (Guest)


Rate this post
useful
not useful
regarding your latest code:

in S1 you have a combination of if-clauses, which can never be 
fullfilled.

if (Qtemp < dividend) then
    ......
    if (Qtemp > dividend) then

If Qtemp is bigger than dividend, you do not enter the outer if-clause.
If it is smaller than dividend, you do not enter the inner if-clause. So 
the inner if-clause will never be entered. (I am aware, that you assign 
a new value to Qtemp inbetween, but this new value will not be 
considered during this run of the process, as Qtemp is a signal, not a 
variable)

I would expect that you get lots of warnings for generating latches. 
Don't do such stuff: use flip-flops (registers) to store your results 
(Qtemp, Counter, ....).  In other words: make assignments to variables 
in clocked processes (in the moment you only do this for the signal 
"state).

Your whole module is build to run only once. You end in s2 and never 
leave it. You do not re-initialize your signals (Qtemp, counter, ....) 
to correct starting values. Your done-flag will be kept high eternally 
(not just for one clk cycle, as I understood the mission.

Omar Rashad wrote:
> So if the input changes before
> completion that should take us back to state s0. How else can I
> implement that?

You could store your input data to internal signals, when you detected a 
rising edge on start with your edge-detector. Then a single cycle with 
start high and dividend and divisor valid will be sufficient to execute 
the whole calculation.

Most probably you describe the FSM in the multi-process style you have 
been taught. I personally prefer a single process style. And as this 
single process will be clock-triggered you will avoid many problems with 
latches.

von Achim S. (Guest)


Rate this post
useful
not useful
Achim S. wrote:
> In other words: make assignments to variables
> in clocked processes (in the moment you only do this for the signal
> "state).

Aaah, I didn't want to write that.

Don't make assignments to variables at all! (unless you really know what 
you're doing). I meant:

make assignments to signals in clocked processes

von Lattice User (Guest)


Rate this post
useful
not useful
Just a little observation:

The two combinatorial processes have incomplete sensitivity lists.

von Omar Rashad (Guest)


Rate this post
useful
not useful
Thanks for all the input. I have used most of your insight to make 
changes in the code. It is still not working though and I used the 
waveform view to analyze what is happening: counter is being incremented 
to 1 (but quotiend is never assigned counter so it remains 0 for some 
reason whil counter is 1). System stays in s1 indefinitely and I do not 
know why...
1
library ieee;
2
use ieee.std_logic_1164.all;
3
use ieee.numeric_std.all;
4
5
entity divider is 
6
  port 
7
  ( 
8
    clk      : in std_logic; 
9
    start    : in std_logic; 
10
    dividend : in std_logic_vector(7 downto 0); 
11
    divisor  : in std_logic_vector(7 downto 0); 
12
    done     : out std_logic; 
13
    quotient : out std_logic_vector(7 downto 0) 
14
  ); 
15
end entity divider;
16
17
architecture behavior of divider is
18
signal Qtemp, counter: std_logic_vector (7 downto 0):=(others=>'0');
19
signal complete: std_logic := '0';
20
type state_type is (s0, s1, s2);
21
signal state: state_type := s0;
22
signal n_state: state_type;
23
24
begin
25
26
process (clk)
27
begin
28
  if (clk = '1' and clk'event) then
29
    state <= n_state;
30
  end if;
31
end process;
32
33
process (start, dividend, divisor, counter, state)
34
begin
35
  case state is
36
    when s0 => if (start = '1') then
37
                 n_state <= s1;
38
               else
39
                 n_state <= s0;
40
               end if;
41
    when s1 => if (start = '0') then
42
                 n_state <= s0;
43
               elsif (complete = '1') then
44
                 n_state <= s2;
45
               else
46
                 n_state <= s1; 
47
               end if;
48
    when s2 => n_state <= s0;
49
  end case;
50
end process;
51
52
process (state)
53
begin
54
  case state is
55
    when s0 => Qtemp <= (others =>'0'); 
56
               quotient <= (others => '0'); 
57
               counter <= (others => '0');
58
               done <= '0';
59
    
60
    when s1 => if (divisor = dividend) then
61
                 counter <= "00000001";
62
                 complete <= '1';
63
                 quotient <= counter;
64
               elsif (divisor > dividend) then
65
                 counter <= (others => '0');
66
                 complete <= '1';
67
                 quotient <= counter;
68
               elsif (Qtemp < dividend) then
69
                 Qtemp <= std_logic_vector (unsigned(Qtemp) + unsigned(divisor));
70
                 counter <= std_logic_vector(unsigned(counter) + 1);
71
                 if (Qtemp > dividend) then
72
                   counter <= std_logic_vector(unsigned(counter)-1);   
73
                   complete <= '1';
74
                 end if;               
75
                 quotient <= counter; 
76
                 done <= '0';
77
               else 
78
                 quotient <= counter; 
79
                 done <= '0'; 
80
                 complete <= '1';
81
               end if;
82
    
83
    when s2 => quotient <= counter; 
84
               done <= '1';
85
  end case;
86
end process;
87
end behavior;

von Achim S. (Guest)


Rate this post
useful
not useful
that's a simulation problem, which Lattice User already mentioned. The 
"third process" (it might be a good idea to give a name to processes) 
has only "state" in its sensitivity list. So this process only is 
evaluated by the simulator, when state changes (i.e. only once for state 
s1).

The hardware would not care about this incorrect sensitivity list. But 
in hardware you would still have worse problems, since you still don't 
store results in clock-triggered registers.

von Omar Rashad (Guest)


Rate this post
useful
not useful
Achim S. wrote:
> regarding your latest code:
>
> in S1 you have a combination of if-clauses, which can never be
> fullfilled.
>
> if (Qtemp < dividend) then
>     ......
>     if (Qtemp > dividend) then
>
> If Qtemp is bigger than dividend, you do not enter the outer if-clause.
> If it is smaller than dividend, you do not enter the inner if-clause. So
> the inner if-clause will never be entered. (I am aware, that you assign
> a new value to Qtemp inbetween, but this new value will not be
> considered during this run of the process, as Qtemp is a signal, not a
> variable)

I have never heard of this before. This is a process and everything is 
executed sequentially. Isn't that the case? Are you sure of this? I do 
not mean to undermine your experience but I never heard of this before. 
Updating the value of Qtemp in between doesn't register until the next 
run? That could be the reason...

> I would expect that you get lots of warnings for generating latches.
> Don't do such stuff: use flip-flops (registers) to store your results
> (Qtemp, Counter, ....).  In other words: make assignments to variables
> in clocked processes (in the moment you only do this for the signal
> "state).
>
> Your whole module is build to run only once. You end in s2 and never
> leave it. You do not re-initialize your signals (Qtemp, counter, ....)
> to correct starting values. Your done-flag will be kept high eternally
> (not just for one clk cycle, as I understood the mission.

I fixed that in my most updated code. Please take a look at it :D

von Lothar M. (Company: Titel) (lkmiller) (Moderator)


Rate this post
useful
not useful
Achim S. wrote:
> The "third process" (it might be a good idea to give a name to
> processes) has only "state" in its sensitivity list. So this process
> only is evaluated by the simulator, when state changes (i.e. only once
> for state s1).
Lets keep things short: the sensitivity list is INCOMPLETE. Therefore 
the simulation is simply ans definitely WRONG. It will NOT match to real 
hardware behaviour.

Try that and you will see some magic changes:
1
process (state, counter, divisor, dividend, qtemp)
2
begin
Keep in mind: each signal that requires a process to be recalculated 
must be in the sensitivity list. Or easier: each signal on the right 
side of an assignment (<=) or used in a case or used with an if-elsif 
must be in the sensitivity list.

Omar Rashad wrote:
> This is a process and everything is executed sequentially. Isn't that
> the case?
In real hardware the whole process (as the whole description) will be 
implemented in parallel. Each state, each case, each if-elsif will be 
present in parallel beside each other on the FPGA.

Omar Rashad wrote:
>> If Qtemp is bigger than dividend, you do not enter the outer if-clause.
>> If it is smaller than dividend, you do not enter the inner if-clause. So
>> the inner if-clause will never be entered. (I am aware, that you assign
>> a new value to Qtemp inbetween, but this new value will not be
>> considered during this run of the process, as Qtemp is a signal, not a
>> variable)
> I have never heard of this before. This is a process and everything is
> executed sequentially. Isn't that the case?
It is.
But signals are updated at the END of a process. They KEEP there 
INITIAL value THROUGHOUT the process and so they do NOT take an assigned 
value IMMEDIATELY!
The behave entirely different from variables!
Lets take this code snippet and lets assume, that Qtemp is 55 at the 
start, and also that the divisor is 5 at the start. Then I write the 
value of Qtemp in the front of the lines:
1
55 process (state) -- sesitivity list is incomplete!
2
   begin
3
    case state is
4
    when s0 => 
5
               :
6
    
7
    when s1 => if (divisor = dividend) then
8
               :
9
               elsif (divisor > dividend) then
10
               :
11
55             elsif (Qtemp < dividend) then
12
55               Qtemp <= std_logic_vector (unsigned(Qtemp) + unsigned(divisor));
13
                 counter <= std_logic_vector(unsigned(counter) + 1);
14
55               if (Qtemp > dividend) then
15
                   counter <= std_logic_vector(unsigned(counter)-1);   
16
                   complete <= '1';
17
                 :
18
                 :
19
               end if;
20
      
21
      when s2 => quotient <= counter; 
22
                 done <= '1';
23
     end case;
24
60 end process;
So remember: signals keep there initial values throughout the process. 
They are updated at the end of the process with the last value assinged 
to them.
What value will a,b,c and d have here after "running" threough the 
process:
1
  signal a : integer := 1;
2
  signal b : integer := 2;
3
  signal c : integer := 3;
4
  :
5
  process (a,b,c) 
6
  begin
7
     a <= b+c;
8
     c <= c+c;
9
     b <= a+c;
10
     a <= a-b;
11
     b <= b-1;
12
     c <= 2*b;
13
     a <= c;
14
     b <= c-a;
15
     c <= a;
16
  end  process;
Try to find it out. If you don't get it, then simulate it!
A little hint: due to the behaviour of signals you must only look 
backwards at the last three assignments!
Have a &/very, very close look/ at this fact, otherwise you will 
encouter some similar problems later on...

> I do not mean to undermine your experience but I never heard of this
> before.
Yes, you are new to VHDL. You will learn further on...

: Edited by Moderator
von Achim S. (Guest)


Rate this post
useful
not useful
Hello Omar,

Lothar already answered your questions in detail.

You are experiencing the same problem as many peoble, which are used to 
software (running sequentially on a CPU) and now look the same way on 
VHDL code.

But VHDL Code is no software in that sense. VHDL code may describe 
something sequentially, but the described hardware will be present in 
parallel and work in parallel. You may e.g. describe first, that you 
need an AND-gate, and you describe second, that you need an XOR-gate. 
Once this is mapped to real hardware, you will have all the gates in 
parallel, though your description was one after the other.

Have a look at the RTL-viewer. It shows you, what parallel hardware is 
generated from your sequential description. Understand what descriptions 
lead to registers (good) and what descriptions lead to latches and 
combinatorial loops (in most cases bad). Then you'll be able to use VHDL 
successfully ;-)

von Lothar M. (Company: Titel) (lkmiller) (Moderator)


Rate this post
useful
not useful
Lothar Miller wrote:
> A little hint: due to the behaviour of signals you must only look
> backwards at the last three assignments!
A second hint: the order of the last three assignments is arbitrary. You 
will get the very same results with this:
1
     :
2
     b <= c-a;
3
     a <= c;
4
     c <= a;
5
  end  process;
And also with this:
1
     :
2
     a <= c;
3
     c <= a;
4
     b <= c-a;
5
  end  process;

: Edited by Moderator
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.