VHDL simulator error message - please help

[Daku]

Could some VHDL guru please help ? My VHDL simulator is giving error
message as:
"multiple driver on unguarded signal `index 0`"
What would be a good way to get around this problem ? The source code
is below for reference:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_arith.ALL;
use IEEE.STD_LOGIC_unsigned.ALL;
use IEEE.NUMERIC_STD.ALL;


ENTITY ram IS
port ( CEB : in std_logic;
WEB : in std_logic;
REB : in std_logic;
INN : in std_logic_vector(0 to 31);
OUTT : out std_logic_vector(0 to 31)
);
END ram;

ARCHITECTURE dataflow_view OF ram IS
CONSTANT MAX : integer := 32;
SIGNAL index : std_logic_vector (0 to 31) :=
('0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0');
SIGNAL cpriority : std_logic_vector (0 to 7) :=
('0','0','0','0','0','0','0','0');
SIGNAL spriority : std_logic_vector (0 to 7) :=
('0','0','0','0','0','0','0','0');

SUBTYPE TYPE_WORD IS std_logic_vector (0 to 31);
TYPE TYPE_RAM IS ARRAY(0 TO 31) OF TYPE_WORD;
SIGNAL memory : TYPE_RAM := ((OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'),
(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),
(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'));



BEGIN

RAM_0 : PROCESS( WEB )
BEGIN
IF RISING_EDGE(WEB) THEN
IF (REB='0') THEN
FOR I IN index'RANGE LOOP
IF index(I) = '0' THEN
index(I) <= '1';
cpriority <= INN(24 TO 31);
memory(I) <= INN;
EXIT;
END IF;
END LOOP;
END IF; -- REB='0'
IF (CONV_INTEGER(spriority) <
CONV_INTEGER(cpriority)) THEN
spriority <= cpriority;
END IF;
END IF; -- rising_edge
END PROCESS RAM_0;

RAM_1 : PROCESS( REB )
BEGIN
IF RISING_EDGE(REB) THEN
IF (WEB='0') THEN
FOR I IN index'RANGE LOOP
IF index(I) = '1' THEN
index(I) <= '0';
EXIT;
END IF;
END LOOP;
OUTT <= memory(I);
END IF; -- WEB='0'
END IF; -- rising
END PROCESS RAM_1;

END dataflow_view;

Any hints, suggestions would be of immense help. Thanks in advance for
your help.

 

[Tricky]

Could some VHDL guru please help ? My VHDL simulator is giving error
message as:
"multiple driver on unguarded signal `index 0`"
What would be a good way to get around this problem ? The source code
is below for reference:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_arith.ALL;
use IEEE.STD_LOGIC_unsigned.ALL;
use IEEE.NUMERIC_STD.ALL;

Dont load Numeric std and std_logic_arith/unsigned at the same time.
You're liable to confuse all sorts of things. These libraries are not
compatible with each other. Preferably - use numeric_std.

ENTITY ram IS
  port ( CEB      : in std_logic;
         WEB      : in std_logic;
         REB      : in std_logic;
         INN      : in  std_logic_vector(0 to 31);
         OUTT     : out std_logic_vector(0 to 31)
  );
END ram;

ARCHITECTURE dataflow_view OF ram IS
    CONSTANT MAX   : integer := 32;
    SIGNAL index   : std_logic_vector (0 to 31) :=
('0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0');

Why not initialise to (others => '0') ? instead of the overly long
expression? If you need access to individual bits, why not just use
hex notation? index := x"0000_0000" ;

    SIGNAL cpriority : std_logic_vector (0 to 7) :=
('0','0','0','0','0','0','0','0');
    SIGNAL spriority : std_logic_vector (0 to 7) :=
('0','0','0','0','0','0','0','0');

    SUBTYPE TYPE_WORD IS std_logic_vector (0 to 31);
    TYPE TYPE_RAM IS ARRAY(0 TO 31) OF TYPE_WORD;
    SIGNAL memory : TYPE_RAM := ((OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'), (OTHERS=>'0'),
(OTHERS=>'0'),
(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),
(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'),(OTHERS=>'0'));

You really like to be explicit dont you. whats wrong with ( others =>
(others => '0') ); ?

BEGIN

   RAM_0 :  PROCESS( WEB )
     BEGIN
      IF RISING_EDGE(WEB) THEN
       IF (REB='0') THEN
         FOR I IN index'RANGE LOOP
           IF index(I) = '0' THEN
             index(I) <= '1';
             cpriority <= INN(24 TO 31);
             memory(I) <= INN;
             EXIT;
           END IF;
         END LOOP;
       END IF; -- REB='0'
       IF (CONV_INTEGER(spriority) <
           CONV_INTEGER(cpriority)) THEN
            spriority <= cpriority;
       END IF;
     END IF; -- rising_edge
   END PROCESS RAM_0;

   RAM_1 :  PROCESS( REB )
     BEGIN
      IF RISING_EDGE(REB) THEN
       IF (WEB='0') THEN
         FOR I IN index'RANGE LOOP
           IF index(I) = '1' THEN
            index(I) <= '0';
            EXIT;
           END IF;
         END LOOP;
        OUTT <= memory(I);
       END IF; -- WEB='0'
     END IF; -- rising
   END PROCESS RAM_1;

END dataflow_view;

Any hints, suggestions would be of immense help. Thanks in advance for
your help.

The problem with the code is that you have the index signal assigned
in 2 separate processes You are only allowed to assign a signal from 1
process. In addition you're reading reb and web as if they were
clocks. You are likely to get some potential timing failures if you
tried this on an FPGA.

 

[Daku]

The problem with the code is that you have the index signal assigned
in 2 separate processes You are only allowed to assign a signal from 1
process.

This is very hard to believe.
The VHDL language reference clearly states that VHDL's model
of a system consists of a static network of concurrent processes
communicating via signals. A process has drivers for certain
processes and a signal may be driven by multiple processes.

 

[Mike Treseler]

The VHDL language reference clearly states that VHDL's model
of a system consists of a static network of concurrent processes
communicating via signals. A process has drivers for certain
processes and a signal may be driven by multiple processes.

True, but for synthesis, this only applies to
tri-state device pin descriptions.

-- Mike Treseler

 

[Paul Uiterlinden]

This is very hard to believe.

Your beliefs are irrelevant here and I'm not interrested in them in the
slightest.
;-)

The VHDL language reference clearly states that VHDL's model
of a system consists of a static network of concurrent processes
communicating via signals. A process has drivers for certain
processes and a signal may be driven by multiple processes.

As long as the signal is of a resolved type, or in case of an aggregate
signal its members must be resolved. The latter is the case in your code.
So the error message of your simulator is not correct. Get a decent
simulator.

Then you will find the next compile error:

FOR i IN index'RANGE LOOP
IF index(i) = '1' THEN
index(i) <= '0';
EXIT;
END IF;
END LOOP;
outt <= memory(i); <=== ERROR

ERROR: Unknown identifier "i"

A loop indentifier is a constant that only lives within the loop. Outside it
it does not exits. If you want the value of i after the exit, you must
assign it in the loop to another variable. And the name of that variable
must be different from i, otherwise it will be hidden by the loop constant
i. And by the way, I think you also must take care of the case where there
is no '1' bit in the index vector.

And then if you get your code compiling, you will find it will not work due
to the multiple drivers on signal index (as already spotted by Tricky). The
result will be all 'X'. Why? Read up on multiple drivers and resolution
functions.

A good way to get around the multiple driver problem: don't do it. Drive a
signal only from one process. How? Depends what your design intent is. What
is the purpose of your VHDL anyway? Should it be synthesizable? Or
testbench code (behavioral)?

 

[Kenn Heinrich]

This is very hard to believe.
The VHDL language reference clearly states that VHDL's model
of a system consists of a static network of concurrent processes
communicating via signals. A process has drivers for certain
processes and a signal may be driven by multiple processes.

To refine some other comments: yes, VHDL the elegant parallel simulation
language lets you do that, and more. However, the subset of VHDL which
can be used as the front-end language for gate-grinding hardware guys is
considerably less flexible. Key words are "resolution function" and
"multiple drivers" - the comp.lang.vhdl FAQ actually describes this stuff
pretty well.

However, in your case, it *does* look like your code should not give the
error you describe - both drivers contend for a std_logic scalar signal
(which *is* resolved, and so should be OK). Some simulators or
synthesizers will give a *warning* just to point out to you that you
might be heading off the rails.

Unfortunately, I suspect that if you try to synthesize this you're in
for a lot of pain for a lot of other reasons - the handling of clocks
and timing is going to give you a lot of trouble. The biggest issue I
see in this code is not simply that you're driving the same signal from
two processes (which *can* be safe in very limited contexts), but that
it's driven from two processes which operate *asynchronously* to each
other, on different clocks. And worse than that, they each check each
other's clock. This has all the hallmarks of a metastable,
race-condition-filled, train wreck if you try to synthesize it.

- Kenn

 

[Daku]

Thank you sir for your insightful comments. I
agree fully with you about the "asynchronous" nature of the design.
However, I did not expect
the signal resolution problem, as you have
pointed out. Looks like the Alliance 5.0 compiler/
simulator is a piece of crap/junk/shit.

 

[Tricky]

Thank you sir for your insightful comments. I
agree fully with you about the "asynchronous" nature of the design.
However, I did not expect
the signal resolution problem, as you have
pointed out. Looks like the Alliance 5.0 compiler/
simulator is a piece of crap/junk/shit.

To refine some other comments: yes, VHDL the elegant parallel simulation
language lets you do that, and more.  However, the subset of VHDL which
can be used as the front-end language for gate-grinding hardware guys is
considerably less flexible.  Key words are "resolution function" and
"multiple drivers" - the comp.lang.vhdl FAQ actually describes this stuff
pretty well.

However, in your case, it *does* look like your code should not give the
error you describe - both drivers contend for a std_logic scalar signal
(which *is* resolved, and so should be OK). Some simulators or
synthesizers will give a *warning* just to point out to you that you
might be heading off the rails.

Unfortunately, I suspect that if you try to synthesize this you're in
for a lot of pain for a lot of other reasons - the handling of clocks
and timing is going to give you a lot of trouble. The biggest issue I
see in this code is not simply that you're driving the same signal from
two processes (which *can* be safe in very limited contexts), but that
it's driven from two processes which operate *asynchronously* to each
other, on different clocks. And worse than that, they each check each
other's clock. This has all the hallmarks of a metastable,
race-condition-filled, train wreck if you try to synthesize it.

 - Kenn

But it is a problem:

Consider this: at 5ns WEB has a rising edge event and index(0) = '0';
web then falls to '0'. REB then has a rising_edge event at 10ns .
Because index(0) is already being driven with '0' from RAM_0, you're
now trying to drive '1' on it. The output result will mean index(0) is
now 'X'. This is the multiple constant driver problem.

The alliance compiler seems to be working fine.

 

[Kenn Heinrich]

Thank you sir for your insightful comments. I
agree fully with you about the "asynchronous" nature of the design.
However, I did not expect
the signal resolution problem, as you have
pointed out. Looks like the Alliance 5.0 compiler/
simulator is a piece of crap/junk/shit.






But it is a problem:

Consider this: at 5ns WEB has a rising edge event and index(0) = '0';
web then falls to '0'. REB then has a rising_edge event at 10ns .
Because index(0) is already being driven with '0' from RAM_0, you're
now trying to drive '1' on it. The output result will mean index(0) is
now 'X'. This is the multiple constant driver problem.

This is a true physical problem in the design. I would still expect
that the simulator should happily, and with full approval of the
language spec, spit out an 'X' here, since ' X' is the official
resolution of two drivers spitting out an std_logic '0' and a '1'. The
user can then ask "why the heck does it go to 'X'?" and discover his
timing problem.

The alliance compiler seems to be working fine.

I still don't agree with that. If I'm wrong, I'd like to see the proper
reference from the LRM so I can understand why. True, the compiler had
a beneficial *human* function, sending this poor soul out onto the
internet for help, whereby numerous other problems were found. But I
still suspect the compiler itself should not be indicating an error
here.

- Kenn

---------------------------------

 

[KJ]

I still don't agree with that.
But I
still suspect the compiler itself should not be indicating an error
here.

Since Alliance is "a VHDL compiler and simulator, logic synthesis
tools, and automatic place and route tools." [1] then whether or not
the reported error of "multiple driver on unguarded signal `index 0`"
is valid or not would depend on whether Daku is simulating or
synthesizing. If Daku is simulating, then there should be no error
since it will simulate just fine...that is, once you get rid of the
syntax errors in the posted code, one being the use of loop variable
'i' that is used outside of the loop (as pointed out by Paul), the
other being the initialization constant of '0-' as one of the bits to
initialize the index vector. On the other hand, if Daku is trying to
synthesize something then the error is valid if the target technology
does not support internal tri-state drivers.

If the error reported actually is the one reported by Alliance when
compiling the posted code 'as-is', then Alliance would seem to be
rather poor in reporting simple syntax errors. Using Modelsim, I got
the following...

** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
\ZPhase1_EM1_PCBA_Cadence.vhd(1378): near "'": syntax error
** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
\ZPhase1_EM1_PCBA_Cadence.vhd(1405): (vcom-1136) Unknown identifier
"index".
....more errors because of unknwn 'index'.

This is caused by one of the bits in index being initialized to '0-'.
Fixing that leads to...

** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
\ZPhase1_EM1_PCBA_Cadence.vhd(1433): (vcom-1136) Unknown identifier
"i".
** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
\ZPhase1_EM1_PCBA_Cadence.vhd(1439): VHDL Compiler exiting

This is caused by loop variable being used outside the loop. Fixing
that and it compiles just fine (for simulation, since this is
Modelsim).

Kevin Jennings

[1] http://www-asim.lip6.fr/recherche/alliance/

 

[Mike Treseler]

The alliance compiler seems to be working fine.

I still don't agree with that. If I'm wrong, I'd like to see the proper
reference from the LRM so I can understand why.

It's not a language error.
It's a synthesis error.
Two outputs shorted together.

-- Mike Treseler

 

[Daku]

The Alliance package consists of a set of tools
to be run in sequence to perform the synthesis task.
First of all, Alliance package provides a tool called 'genpat' to
generate test input for the circuit to be tested, and the test
pattern specification is a simple C file. With the test input file in
place,
1. Use Alliance 'vasy' tool to convert the "as-is" VHDL code to a set
of boolean equations
2. Use Alliance 'asimut' tool (the main simulator)
on the set of boolean equations and the test input
to check if the set of generated boolean equations works with the
test input - NO error messages at
this stage
3. Use Alliance 'boom' tool to
optimize (factorize/minimize) the boolean equations based on user
specified area/delay requirements
4. Use Alliance 'boog' tool to map boolean nodes to a set of standard
cells - using pseudo 0.35 u technology
5. Use Allinace 'loon' tool to insert buffers in critical path and
using standard cell library (see 4. above) and generate structural
netlist
6. Run asimut simulator on structural netlist from step 5. ERROR
GENERATED AND SIMULATOR FAILS

So, the errors about loop index 'i' are not caught in steps 1 and 2
above, not to mention the timing bugs.

Since Alliance is "a VHDL compiler and simulator, logic synthesis
tools, and automatic place and route tools." [1] then whether or not
the reported error of "multiple driver on unguarded signal `index 0`"
is valid or not would depend on whether Daku is simulating or
synthesizing. If Daku is simulating, then there should be no error
since it will simulate just fine...that is, once you get rid of the
syntax errors in the posted code, one being the use of loop variable
'i' that is used outside of the loop (as pointed out by Paul), the
other being the initialization constant of '0-' as one of the bits to
initialize the index vector. On the other hand, if Daku is trying to
synthesize something then the error is valid if the target technology
does not support internal tri-state drivers.

If the error reported actually is the one reported by Alliance when
compiling the posted code 'as-is', then Alliance would seem to be
rather poor in reporting simple syntax errors. Using Modelsim, I got
the following...

** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
\ZPhase1_EM1_PCBA_Cadence.vhd(1378): near "'": syntax error
** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
\ZPhase1_EM1_PCBA_Cadence.vhd(1405): (vcom-1136) Unknown identifier
"index".
...more errors because of unknwn 'index'.

This is caused by one of the bits in index being initialized to '0-'.
Fixing that leads to...

** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
\ZPhase1_EM1_PCBA_Cadence.vhd(1433): (vcom-1136) Unknown identifier
"i".
** Error: C:\Sim\Zpoc_Sim\HDL\ZPhase1_EM1_PCBA_Cadence
\ZPhase1_EM1_PCBA_Cadence.vhd(1439): VHDL Compiler exiting

This is caused by loop variable being used outside the loop. Fixing
that and it compiles just fine (for simulation, since this is
Modelsim).

Kevin Jennings

[1]http://www-asim.lip6.fr/recherche/alliance/