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
>

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 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.

I don't think so. I use this very often to output a variable, it works 
absolutely fine.


> Garbage in, garbage out.

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=A0am, "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
> > =A0 =A0port(
> > =A0 =A0 =A0 =A0 =A0 =A0Clock : in std_ulogic;
> > =A0 =A0 =A0 =A0 =A0 =A0Foo : out std_ulogic;
> > =A0 =A0 =A0 =A0 =A0 =A0Bar : out std_ulogic);
> >end entity Test;
>
> >architecture Arch of Test is
> >begin
> > =A0 =A0Foo <=3D '1';
> > =A0 =A0Bar <=3D '1';
>
> > =A0 =A0process(Clock) is
> > =A0 =A0 =A0 =A0 =A0 =A0variable Temp : std_ulogic :=3D '0';
> > =A0 =A0begin
> > =A0 =A0 =A0 =A0 =A0 =A0if rising_edge(Clock) then
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Temp :=3D not Temp;
> > =A0 =A0 =A0 =A0 =A0 =A0end if;
> > =A0 =A0 =A0 =A0 =A0 =A0Bar <=3D Temp;
> > =A0 =A0end 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 -

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

On May 16, 11:15=A0pm, 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
> =A0 =A0 =A0 =A0 port(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Clock : in std_ulogic;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Foo : out std_ulogic;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bar : out std_ulogic);
> end entity Test;
>
> architecture Arch of Test is
> begin
> =A0 =A0 =A0 =A0 Foo <=3D '1';
> =A0 =A0 =A0 =A0 Bar <=3D '1';
>
> =A0 =A0 =A0 =A0 process(Clock) is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 variable Temp : std_ulogic :=3D '0';
> =A0 =A0 =A0 =A0 begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if rising_edge(Clock) then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Temp :=3D not Temp;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bar <=3D Temp;
> =A0 =A0 =A0 =A0 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

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 <=3D '1';

The second one is in a process section:

    Bar <=3D 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.

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.

I confirm that XST doesn't have any problem with it.

Nicolas

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]

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

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=A0pm, 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=A0pm, 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 -

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=A0pm, 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=A0pm, 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 -

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.

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:

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
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=A0am, 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. =A0This is no doubt another bug introduced
> with the "new parsers" for S6, V6 and newer parts -
> hence Ed's question about target part.
>
> - Gabor

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.

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

Sounds like it is hitting Chris on the head too. :-)

-- 

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com