EmbDev.net

Forum: FPGA, VHDL & Verilog compilation error


von amitai (Guest)


Attached files:

Rate this post
useful
not useful
Hi to all,

A homework task I got is to create a component which receives
positive numbers and gives the output of A+B-C+D-E...

I got a few error's which seem to be all connected to each other,
but I don't manage to understand what the problem is.

The code is:

 library ieee;
use ieee.std_logic_1164.all;

-- mux2to1 Component ----
-------------
entity mux2_1 is port
       (d0    : in  integer;
    d1    : in  integer;
    sel   : in  bit;
    d_out : out integer);
end entity;

architecture mux2_1_arc of mux2_1 is

 begin
 with sel select
   d_out <= d0 when '0',
            d1 when '1';
end architecture;
--------------------

library ieee;
use ieee.std_logic_1164.all;
use std.env.all;

-- d_ff for result Component ----  (integer input)
-------------
entity d_ff_res is port
     (clk_ff        : in std_logic;
        d_ff_in_res   : in integer;
    d_ff_out_res  : out integer);
end entity;

architecture w_sens_list of d_ff_res is

begin
  process (clk_ff)
    begin
    if clk_ff'event and clk_ff='1' then
      d_ff_out_res <= d_ff_in_res;
    end if;
  end process;

end architecture;
----------------------

library ieee;
use ieee.std_logic_1164.all;
use std.env.all;

-- d_ff for mux Component ----    (bit input)
-------------
entity d_ff_mux is port
     (clk_ff        : in std_logic;
        d_ff_in_mux   : in bit;
    d_ff_out_mux  : out bit);
end entity;

architecture w_sens_list of d_ff_mux is

begin
  process (clk_ff)
    begin
    if clk_ff'event and clk_ff='1' then
      d_ff_out_mux <= d_ff_in_mux;
    end if;
  end process;

end architecture;
----------------------

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_signed.all;
use std.env.all;

-- main Component  ---
-----------------------
entity taylor_seq is generic (n : positive := 5);
  port (D_in  : in  integer;
        Rst_n : in  std_logic;
    clk   : in  std_logic;
    RES   : out integer );
end entity;

architecture arc_taylor_se of taylor_seq is

  signal mux_o, last_RES, tran_RES  : integer;
  signal sel_mux, rev_sel : bit;
  constant CCT      : time := 10 ns;

  begin
    last_RES <= 0;
  mux_o    <= 0;
  RES      <= 0;
  sel_mux  <= '0';
  tran_RES <= 0;
  Rst_n <= '1';
  rev_sel <= NOT sel_mux;
  clk <= not (clk) after CCT / 2;

  my_mux : entity work.mux2_1 port map (
        d0       => D_in,
        d1       => D_in,
        sel      => sel_mux,
        d_out    => mux_o);

  MUX_DFF : entity work.d_ff_mux port map (
        d_ff_in_mux    => rev_sel,
        d_ff_out_mux   => sel_mux,
        clk_ff         => clk);

  RES_DFF : entity work.d_ff_res port map (
    d_ff_in_res    => tran_RES,
    d_ff_out_res   => last_RES,
    clk_ff         => clk);

  FAs_generator: for i in 1 to n generate

      process (clk)
     begin
      if rising_edge (clk) then
      if Rst_n='1' then
        if sel_mux = '1' then
          tran_RES <= last_RES+mux_o;
        else
          tran_RES <= last_RES-mux_o;
        end if;

        RES <= tran_RES;

      else        -- Rst_n= 0
       RES   <= 0;
       Rst_n <= '1';
      end if;
      end if;
    end process;
  end generate;
end architecture;



and the compiler's response is:

 ** Error: ex4.vhd(98): Cannot drive signal 'Rst_n' of mode IN.
# ** Error: ex4.vhd(100): Cannot drive signal 'clk' of mode IN.
# -- Loading entity mux2_1
# -- Loading entity d_ff_mux
# -- Loading entity d_ff_res
# ** Error: ex4.vhd(134): Cannot drive signal 'Rst_n' of mode IN.
# ** Warning: [5] ex4.vhd(83): Nonresolved signal 'RES' may have 
multiple sources.
#   Drivers:
#     ex4.vhd(95):Conditional signal assignment line__95
#     ex4.vhd(120):Process line__120
#        Driven at:
#           ex4.vhd(130)
# ** Error: ex4.vhd(88): Nonresolved signal 'mux_o' has multiple 
sources.
#   Drivers:
#     ex4.vhd(106):Statement my_mux
#     ex4.vhd(94):Conditional signal assignment line__94
# ** Error: ex4.vhd(88): Nonresolved signal 'last_RES' has multiple 
sources.
#   Drivers:
#     ex4.vhd(116):Statement RES_DFF
#     ex4.vhd(93):Conditional signal assignment line__93
# ** Warning: [5] ex4.vhd(88): Nonresolved signal 'tran_RES' may have 
multiple sources.
#   Drivers:
#     ex4.vhd(97):Conditional signal assignment line__97
#     ex4.vhd(120):Process line__120
#        Driven at:
#           ex4.vhd(125)
# ** Error: ex4.vhd(89): Nonresolved signal 'sel_mux' has multiple 
sources.
#   Drivers:
#     ex4.vhd(111):Statement MUX_DFF
#     ex4.vhd(96):Conditional signal assignment line__96
# ** Error: ex4.vhd(139): VHDL Compiler exiting
# D:/Modeltech_pe_edu_10.2a/win32pe_edu/vcom failed.



thanks in advance, Amitai

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


Rate this post
useful
not useful
I tend to say that the messages tell the problems fairly clear. Let's 
take the clk:
You define it as an input:
 clk : in std_logic;
But a few lines later you want to drive the clock:
  clk <= not (clk) after CCT / 2;
Also keep in mind that after is NOT synthesizeable!
You can use it in a test bench, but you cannot transfer it to real 
hardware.

Multiple sources are signals driven from more the one assignment.  And 
that's not allowed in VHDL, and it cannot be transferred to hardware 
because it would result in a short circuit of two output drivers...

von amitai (Guest)


Attached files:

Rate this post
useful
not useful
Thanks very much for the quick answer.

I understood the meaning of the clock- it needs to be
controlled from the testbench and not by the component itself.

The problem of the multiple sources I managed to Reduce to one-

# ** Error: checkex4.vhd(103): Nonresolved signal 'cur_RES' has multiple 
sources.

which is the output of the FF whom is responsible for the memory
for the next cycle. I don't see why there is a problem with the code.
(I can guess it's connected to the clock and sync options ?)


Thanks, Amitai

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


Rate this post
useful
not useful
amitai wrote:
> # ** Error: checkex4.vhd(103):
> Nonresolved signal 'cur_RES' has multiple sources.
To be exact: there are two sources. One here:
    cur_RES <= 0;
And the other here:
    d_ff_out   => cur_RES,

You have also a multiple source on cur_sel. Its very similar. You will 
find it yourself now...

Also the sensitivity list of the process taylor_sequnce is completely 
rubbish: clk is not used in the process at all, but rst_n, nxt_RES, 
mux_o and cur_RES are missing. To keep things short: your simulation ist 
totally WRONG! It will look like this process is someway related to clk, 
but in hardware this process will result in a completely combinational 
wiring.


According to your picture I would write the code this way:
1
library ieee;
2
use ieee.std_logic_1164.all;
3
use ieee.std_logic_signed.all; 
4
5
entity taylor_seq is 
6
  port (D_in  : in  integer;
7
        Rst_n : in  std_logic;
8
        clk   : in  std_logic;
9
        RES   : out integer );       
10
end entity;
11
12
architecture arc_taylor_se of taylor_seq is
13
   
14
  signal d,r : integer;
15
  signal invert: std_logic;
16
    
17
  begin  
18
    d  <= D_in;
19
20
    toggle_sign : process (Rst_n,clk) 
21
    begin
22
       if Rst_n='1' then
23
          invert = '0';
24
       elsif rising_edge(clk) then
25
          invert <= not invert;
26
       end if;
27
    end process;
28
  
29
    taylor_sequnce : process (Rst_n,clk)
30
    begin 
31
       if Rst_n='1' then
32
          r <= 0;
33
       elsif rising_edge(clk) then
34
          if invert='0' then
35
             r <= r+d;
36
          else
37
             r <= r-d;
38
          end if;             
39
      end if;  
40
    end process;
41
42
    RES <= r;
43
end architecture;
Thats it, folks...


Of course you can write the code a little bit more chatty and split up 
the code to the elements in the picture:
1
library ieee;
2
use ieee.std_logic_1164.all;
3
use ieee.std_logic_signed.all; 
4
5
entity taylor_seq is 
6
  port (D_in  : in  integer;
7
        Rst_n : in  std_logic;
8
        clk   : in  std_logic;
9
        RES   : out integer );       
10
end entity;
11
12
architecture arc_taylor_se of taylor_seq is
13
   
14
  signal din,dneg,muxo,cr,nr : integer; -- data input ... current result, next result
15
  signal cs, ns: std_logic; -- current and next sign
16
    
17
  begin  
18
    din   <=  D_in;
19
    dneg  <= -D_in;
20
    
21
    -- the mux
22
    muxo <= din when cs='1' else dneg;
23
24
    -- the toggle bit inverter
25
    ns <= not cs;
26
27
    -- the toggle bit FF
28
    toggle_sign : process (Rst_n,clk) 
29
    begin
30
       if Rst_n='1' then
31
          cs <= '0';
32
       elsif rising_edge(clk) then
33
          cs <= ns;
34
       end if;
35
    end process;
36
    
37
    -- the adder
38
    nr <= cr + muxo;
39
40
    -- the result FFs
41
    process (Rst_n,clk)
42
    begin 
43
       if Rst_n='1' then
44
          cr <= 0;
45
       elsif rising_edge(clk) then
46
          cr <= nr;
47
      end if;  
48
    end process;
49
50
    RES <= cr;
51
end architecture;
But why the heck sould anyone go as far as you did and implement a MUX 
or some D-FF as stand-alone components/modules?

von Amitai W. (ami85t)


Attached files:

Rate this post
useful
not useful
I tried using your code and changed it,
because of a few things:
- the meaning of the question I got is that the whole process
  happens after the rising clock ( including the reset)

- as far as I understand, different process work in parallel
  and what I need is that there will be one process which has
  a sync between the 2 parts

The program still doesn't work as expected and the output
has for some reason different clock time then the rest of the
circuit, any idea why?

Thanks, Amitai

PS - the idea of implementing by mux etc. is of the lecturer for some 
reason

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


Rate this post
useful
not useful
> that the whole process happens after the rising clock
A process does not "happen". A process is transferred to real hardware 
and that is "always there". So in hardware a process is "executed 
always".
But in simualtion a process is recalculated when any one of the 
signals in the sensitivity list changes (you will need this information 
later for your "delayed output" problem).

> different process work in parallel
Of course they "work in parallel", because every process will result in 
a piece of silicon with the described function.

> The program
It is not a "program" (thats a term out of the software world!). What 
you have is a "hardware description". If VHDL would be a programming 
language it would be called VHPL...

> still doesn't work as expected
And so: what do you get?

> and the output has for some reason different clock time then the rest
> of the circuit, any idea why?
One blink with the eyes, and there it is. Thats a fake clock due to an 
incomplete sensitivity list.
Try it this way and think about it:
1
:
2
:
3
  toggle_sign : process (clk) 
4
  begin
5
    if rising_edge(clk) then
6
      if Rst_n='0' then
7
        :
8
      end if;
9
    end if;  
10
  end process;
11
12
  RES <= cr;
You see the problem?
> I tried using your code /and changed it/
You changed it without understanding what you are changing.
You could do it also this way by completing the sensitivity list:
1
:
2
:
3
  toggle_sign : process (clk,cr) 
4
  begin
5
    if rising_edge(clk) then
6
       :
7
    end if;    
8
    RES <= cr;
9
  end process;
But you should not mix combinatorial and synchronous parts in one 
process. Thats a good reason to get fired...

> PS - the idea of implementing by mux etc. is of the lecturer for
> some reason
Yes, thats the usual stupid academic structural description style from 
the end of the last millennium. And thats why VHDL is called to be a 
chatty language. No further comment...

BTW: you have a major difference now in your design vs. my design. Your 
reset is synchronous, mine is asynchronous. I don't know which one fits 
to your picture. But your first VHDL descripiton was totally 
asynchronous. And perhaps that was also the intention of your lecturer. 
Synchronous vs. asynchronous reset is another big chapter in hardware 
desription. But you will not hear anything about it in school...

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.