Xilinx ISE Multiple Drivers Error

C

Christopher Head

Guest
Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:

-- test.vhd
library ieee;
use ieee.std_logic_1164.all;

entity Test is
port(
Clock : in std_ulogic;
Foo : out std_ulogic;
Bar : out std_ulogic);
end entity Test;

architecture Arch of Test is
begin
Foo <= '1';
Bar <= '1';

process(Clock) is
variable Temp : std_ulogic := '0';
begin
if rising_edge(Clock) then
Temp := not Temp;
end if;
Bar <= Temp;
end process;
end architecture Arch;

-- test.prj
vhdl work test.vhd

-- test.xst
run
-ifn test.prj
-ofn test.ngc
-p xc6slx9-tqg144-2
-top test
-opt_level 1
-opt_mode speed
-arch arch

$ xst -ifn test.xst
Release 13.4 - xst O.87xd (lin64)
[snip]
Elaborating entity <Test> (architecture <Arch>) from library <work>.
ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
unit Test is connected to following multiple drivers:
ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0: output
signal of instance Power ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd"
Line 16: Driver 1: output signal Temp of instance Flip-Flop

but clearly the signal with multiple drivers is Bar, not Foo!

Thoughts on this?

Chris
 
Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:

-- test.vhd
library ieee;
use ieee.std_logic_1164.all;

entity Test is
port(
Clock : in std_ulogic;
Foo : out std_ulogic;
Bar : out std_ulogic);
end entity Test;

architecture Arch of Test is
begin
Foo <= '1';
Bar <= '1';

process(Clock) is
variable Temp : std_ulogic := '0';
begin
if rising_edge(Clock) then
Temp := not Temp;
end if;
Bar <= Temp;
end process;
end architecture Arch;

-- test.prj
vhdl work test.vhd

-- test.xst
run
-ifn test.prj
-ofn test.ngc
-p xc6slx9-tqg144-2
-top test
-opt_level 1
-opt_mode speed
-arch arch

$ xst -ifn test.xst
Release 13.4 - xst O.87xd (lin64)
[snip]
Elaborating entity <Test> (architecture <Arch>) from library <work>.
ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
unit Test is connected to following multiple drivers:
ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0: output
signal of instance Power ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd"
Line 16: Driver 1: output signal Temp of instance Flip-Flop

but clearly the signal with multiple drivers is Bar, not Foo!

Thoughts on this?

Chris
Click to expand...
Perhaps XST is confused by your clocked process not being a norma
synthesizable style, because the signal assignment is outside of the 'i
rising_edge' section.

Garbage in, garbage out.



---------------------------------------
Posted through http://www.FPGARelated.com
 
Le 17/05/2012 10:44, RCIngham a écrit :
Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:

-- test.vhd
library ieee;
use ieee.std_logic_1164.all;

entity Test is
port(
Clock : in std_ulogic;
Foo : out std_ulogic;
Bar : out std_ulogic);
end entity Test;

architecture Arch of Test is
begin
Foo<= '1';
Bar<= '1';

process(Clock) is
variable Temp : std_ulogic := '0';
begin
if rising_edge(Clock) then
Temp := not Temp;
end if;
Bar<= Temp;
end process;
end architecture Arch;
[...]
Perhaps XST is confused by your clocked process not being a normal
synthesizable style, because the signal assignment is outside of the 'if
rising_edge' section.
Click to expand...
I don't think so. I use this very often to output a variable, it works
absolutely fine.


Garbage in, garbage out.
Click to expand...
Actually not.

What I think happens is that XST reduces ("optimizes") foo and bar to a
single signal, names it foo probably because it's the first declared,
and the complains about the multiple drivers.

Nicolas
 
On May 17, 3:44 am, "RCIngham"
<robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:

-- test.vhd
library ieee;
use ieee.std_logic_1164.all;

entity Test is
   port(
           Clock : in std_ulogic;
           Foo : out std_ulogic;
           Bar : out std_ulogic);
end entity Test;

architecture Arch of Test is
begin
   Foo <= '1';
   Bar <= '1';

   process(Clock) is
           variable Temp : std_ulogic := '0';
   begin
           if rising_edge(Clock) then
                   Temp := not Temp;
           end if;
           Bar <= Temp;
   end process;
end architecture Arch;

-- test.prj
vhdl work test.vhd

-- test.xst
run
-ifn test.prj
-ofn test.ngc
-p xc6slx9-tqg144-2
-top test
-opt_level 1
-opt_mode speed
-arch arch

$ xst -ifn test.xst
Release 13.4 - xst O.87xd (lin64)
[snip]
Elaborating entity <Test> (architecture <Arch>) from library <work>.
ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
unit Test is connected to following multiple drivers:
ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0: output
signal of instance Power ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd"
Line 16: Driver 1: output signal Temp of instance Flip-Flop

but clearly the signal with multiple drivers is Bar, not Foo!

Thoughts on this?

Chris

Perhaps XST is confused by your clocked process not being a normal
synthesizable style, because the signal assignment is outside of the 'if
rising_edge' section.

Garbage in, garbage out.

---------------------------------------
Posted throughhttp://www.FPGARelated.com- Hide quoted text -

- Show quoted text -
Click to expand...
This style (assigning a signal from a variable after the clocked end-
if, in a clocked process) is shown in an example in IEEE 1076.6-2004,
IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis.

If XST has a problem with that, it is a bug.

Like Nicolas, I use this all the time. I rarely use a signal except
for inter-process communications, and this is how I drive signals from
my processes.

Andy
 
Le 17/05/2012 14:09, Andy a écrit :

This style (assigning a signal from a variable after the clocked end-
if, in a clocked process) is shown in an example in IEEE 1076.6-2004,
IEEE Standard for VHDL Register Transfer Level (RTL) Synthesis.

If XST has a problem with that, it is a bug.
Click to expand...
I confirm that XST doesn't have any problem with it.

Nicolas
 
On May 16, 11:15 pm, Christopher Head <ch...@is.invalid> wrote:
Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:

-- test.vhd
library ieee;
use ieee.std_logic_1164.all;

entity Test is
        port(
                Clock : in std_ulogic;
                Foo : out std_ulogic;
                Bar : out std_ulogic);
end entity Test;

architecture Arch of Test is
begin
        Foo <= '1';
        Bar <= '1';

        process(Clock) is
                variable Temp : std_ulogic := '0';
        begin
                if rising_edge(Clock) then
                        Temp := not Temp;
                end if;
                Bar <= Temp;
        end process;
end architecture Arch;

-- test.prj
vhdl work test.vhd

-- test.xst
run
-ifn test.prj
-ofn test.ngc
-p xc6slx9-tqg144-2
-top test
-opt_level 1
-opt_mode speed
-arch arch

$ xst -ifn test.xst
Release 13.4 - xst O.87xd (lin64)
[snip]
Elaborating entity <Test> (architecture <Arch>) from library <work>.
ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
unit Test is connected to following multiple drivers:
ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0: output
signal of instance Power ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd"
Line 16: Driver 1: output signal Temp of instance Flip-Flop

but clearly the signal with multiple drivers is Bar, not Foo!

Thoughts on this?

Chris
Click to expand...
The problem is that you are assigning a value to the signal "Bar" in
two different sections of your code and each of these will have a
driver.

The first one is in the architecture section:

Bar <= '1';

The second one is in a process section:

Bar <= Temp;

You need to get rid of the first assignment and if you want to have a
reset value then you should code this in your process section.

I am assuming that you did not simulate this code because if you had
it would show a 'U' state when the value of Temp is a '0' and in
conflict with the permanent assignment of '1'.

Note; 2nd post try as Google ate my 1st try.

Ed McGettigan
--
Xilinx Inc.
 
On Thu, 17 May 2012 09:04:58 -0700 (PDT)
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

On May 16, 11:15 pm, Christopher Head <ch...@is.invalid> wrote:
[snip]
$ xst -ifn test.xst
Release 13.4 - xst O.87xd (lin64)
[snip]
Elaborating entity <Test> (architecture <Arch>) from library <work>.
ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
unit Test is connected to following multiple drivers:
ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0:
output signal of instance Power ERROR:HDLCompiler:1379 -
"/tmp/vhdl/test.vhd" Line 16: Driver 1: output signal Temp of
instance Flip-Flop

but clearly the signal with multiple drivers is Bar, not Foo!

Thoughts on this?

Chris

The problem is that you are assigning a value to the signal "Bar" in
two different sections of your code and each of these will have a
driver.

[snip]
Click to expand...

Yes, of course that's the problem with the original code. The issue
here is that XST isn't complaining about Bar: it's complaining about
Foo, which has only a single driver!

Chris
 
On Thu, 17 May 2012 11:15:52 +0200
Nicolas Matringe <nicolas.matringe@fre.fre> wrote:

What I think happens is that XST reduces ("optimizes") foo and bar to
a single signal, names it foo probably because it's the first
declared, and the complains about the multiple drivers.

Nicolas
Click to expand...
I think this may have hit the nail on the head. I tried changing the
constant assigned to Foo from '1' to '0', so that now the concurrent
assignments were of different values, and the error message properly
changed to complain about Bar.

Chris
 
On May 18, 5:51 pm, Christopher Head <ch...@is.invalid> wrote:
On Thu, 17 May 2012 09:04:58 -0700 (PDT)





Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
On May 16, 11:15 pm, Christopher Head <ch...@is.invalid> wrote:
[snip]
$ xst -ifn test.xst
Release 13.4 - xst O.87xd (lin64)
[snip]
Elaborating entity <Test> (architecture <Arch>) from library <work>.
ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
unit Test is connected to following multiple drivers:
ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0:
output signal of instance Power ERROR:HDLCompiler:1379 -
"/tmp/vhdl/test.vhd" Line 16: Driver 1: output signal Temp of
instance Flip-Flop

but clearly the signal with multiple drivers is Bar, not Foo!

Thoughts on this?

Chris

The problem is that you are assigning a value to the signal "Bar" in
two different sections of your code and each of these will have a
driver.

[snip]

Yes, of course that's the problem with the original code. The issue
here is that XST isn't complaining about Bar: it's complaining about
Foo, which has only a single driver!

Chris- Hide quoted text -

- Show quoted text -
Click to expand...
Sorry, I missed the Foo vs Bar part of your orignal post. Which FPGA
Family were you using?

Ed McGettigan
--
Xilinx Inc.
 
On May 18, 5:51 pm, Christopher Head <ch...@is.invalid> wrote:
On Thu, 17 May 2012 09:04:58 -0700 (PDT)





Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
On May 16, 11:15 pm, Christopher Head <ch...@is.invalid> wrote:
[snip]
$ xst -ifn test.xst
Release 13.4 - xst O.87xd (lin64)
[snip]
Elaborating entity <Test> (architecture <Arch>) from library <work>.
ERROR:HDLCompiler:1401 - "/tmp/vhdl/test.vhd" Line 16: Signal Foo in
unit Test is connected to following multiple drivers:
ERROR:HDLCompiler:1379 - "/tmp/vhdl/test.vhd" Line 13: Driver 0:
output signal of instance Power ERROR:HDLCompiler:1379 -
"/tmp/vhdl/test.vhd" Line 16: Driver 1: output signal Temp of
instance Flip-Flop

but clearly the signal with multiple drivers is Bar, not Foo!

Thoughts on this?

Chris

The problem is that you are assigning a value to the signal "Bar" in
two different sections of your code and each of these will have a
driver.

[snip]

Yes, of course that's the problem with the original code. The issue
here is that XST isn't complaining about Bar: it's complaining about
Foo, which has only a single driver!

Chris- Hide quoted text -

- Show quoted text -
Click to expand...
Sorry, I missed the distinction between Foo and Bar in the original
post. Which FPGA family were you using?

Note: 3rd post attempt due to Google eating the first two.

Ed McGettigan
--
Xilinx Inc.
 
On Sat, 19 May 2012 15:53:26 -0700 (PDT)
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

Sorry, I missed the Foo vs Bar part of your orignal post. Which FPGA
Family were you using?

Ed McGettigan
--
Xilinx Inc.
Click to expand...
This is targeting xc6slx9-tqg144-2. The original post has the .prj
and .xst files as well as the .vhd.

Chris
 
Christopher Head <chead@is.invalid> writes:

Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:
Click to expand...
Well, at least ancient 10.1 gets it right:

"test.vhd Line 22. Signal Bar has a multi source."
 
Anssi Saari wrote:
Christopher Head <chead@is.invalid> writes:

Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:

Well, at least ancient 10.1 gets it right:

"test.vhd Line 22. Signal Bar has a multi source."


13.4 would probably get it right, too if you target
Click to expand...
a Spartan 3. This is no doubt another bug introduced
with the "new parsers" for S6, V6 and newer parts -
hence Ed's question about target part.

- Gabor
 
On May 23, 8:06 am, Gabor <ga...@szakacs.invalid> wrote:
Anssi Saari wrote:
Christopher Head <ch...@is.invalid> writes:

Hi folks,
I seem to have convinced ISE to output incorrect multiple-driver error
messages. I've reduced the example to the following:

Well, at least ancient 10.1 gets it right:

"test.vhd Line 22. Signal Bar has a multi source."

13.4 would probably get it right, too if you target
a Spartan 3.  This is no doubt another bug introduced
with the "new parsers" for S6, V6 and newer parts -
hence Ed's question about target part.

- Gabor
Click to expand...
Yes, this is why I asked (although it was in the original post). I
have confirmed that the problem only happens with the new parser
(Spartan-6, Virtex-6, 7 Series) and is not present in the original
parser. This is still true for the ISE 14.1 release.

I filed an intenal change request/bug report on the issue to get it
fixed.

Note: I need to stop using Google groups because they continue to drop
my posts (2nd try) unless I logout and then back in again.

Ed McGettigan
--
Xilinx Inc.
 
On Wed, 23 May 2012 10:19:05 -0700 (PDT)
Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:

Yes, this is why I asked (although it was in the original post). I
have confirmed that the problem only happens with the new parser
(Spartan-6, Virtex-6, 7 Series) and is not present in the original
parser. This is still true for the ISE 14.1 release.

I filed an intenal change request/bug report on the issue to get it
fixed.

Note: I need to stop using Google groups because they continue to drop
my posts (2nd try) unless I logout and then back in again.

Ed McGettigan
--
Xilinx Inc.
Click to expand...
Thanks for the attention! Since Xilinx doesn't want bug reports from
university students, I figured this group was an easy way to get some
more eyes on the issue and hopefully get it fixed at some point.

Chris
 
[This followup was posted to comp.arch.fpga and a copy was sent to the
cited author.]

In article <20120518175419.3278d371@kruskal.chead>, chead@is.invalid
says...

I think this may have hit the nail on the head.

Chris
Click to expand...
Sounds like it is hitting Chris on the head too. :)

--

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top