Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Xilinx ISE Multiple Drivers Error
1,414 views
Skip to first unread message
Christopher Head
May 17, 2012, 2:15:34 AM5/17/12
to
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
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
RCIngham
May 17, 2012, 4:44:34 AM5/17/12
to
synthesizable style, because the signal assignment is outside of the 'if
rising_edge' section.
Garbage in, garbage out.
---------------------------------------
Posted through http://www.FPGARelated.com
Nicolas Matringe
May 17, 2012, 5:15:52 AM5/17/12
to
> 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
> synthesizable style, because the signal assignment is outside of the 'if
> rising_edge' section.
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
Andy
May 17, 2012, 8:09:16 AM5/17/12
to
On May 17, 3:44 am, "RCIngham"
> 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
>
> - 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
Ed McGettigan
May 17, 2012, 12:04:58 PM5/17/12
to
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.
Nicolas Matringe
May 17, 2012, 12:33:46 PM5/17/12
to
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.
> 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.
Nicolas
Christopher Head
May 18, 2012, 8:51:51 PM5/18/12
to
On Thu, 17 May 2012 09:04:58 -0700 (PDT)
Ed McGettigan <ed.mcg...@xilinx.com> wrote:
> On May 16, 11:15 pm, Christopher Head <ch...@is.invalid> wrote:
[snip]
Ed McGettigan <ed.mcg...@xilinx.com> wrote:
> On May 16, 11:15 pm, Christopher Head <ch...@is.invalid> wrote:
> > $ 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]
> > 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.
>
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
Christopher Head
May 18, 2012, 8:54:19 PM5/18/12
to
On Thu, 17 May 2012 11:15:52 +0200
Nicolas Matringe <nicolas....@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
Nicolas Matringe <nicolas....@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
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
Ed McGettigan
May 19, 2012, 6:53:26 PM5/19/12
to
>
> - Show quoted text -
Sorry, I missed the Foo vs Bar part of your orignal post. Which FPGA
> - Show quoted text -
Family were you using?
Ed McGettigan
May 19, 2012, 6:55:18 PM5/19/12
to
> Chris- Hide quoted text -
>
> - Show quoted text -
Sorry, I missed the distinction between Foo and Bar in the original
>
> - Show quoted text -
post. Which FPGA family were you using?
Note: 3rd post attempt due to Google eating the first two.
Christopher Head
May 20, 2012, 5:51:29 PM5/20/12
to
On Sat, 19 May 2012 15:53:26 -0700 (PDT)
Ed McGettigan <ed.mcg...@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
Ed McGettigan <ed.mcg...@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.
and .xst files as well as the .vhd.
Chris
Anssi Saari
May 22, 2012, 10:21:14 AM5/22/12
to
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:
> 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 Line 22. Signal Bar has a multi source."
Gabor
May 23, 2012, 11:06:27 AM5/23/12
to
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
Ed McGettigan
May 23, 2012, 1:19:05 PM5/23/12
to
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.
Christopher Head
May 26, 2012, 1:10:13 PM5/26/12
to
On Wed, 23 May 2012 10:19:05 -0700 (PDT)
Ed McGettigan <ed.mcg...@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
Ed McGettigan <ed.mcg...@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.
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
Michael Karas
May 27, 2012, 2:44:43 PM5/27/12
to
[This followup was posted to comp.arch.fpga and a copy was sent to the
cited author.]
In article <20120518175...@kruskal.chead>, ch...@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
cited author.]
In article <20120518175...@kruskal.chead>, ch...@is.invalid
says...
> I think this may have hit the nail on the head.
>
Sounds like it is hitting Chris on the head too. :-)
--
Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
0 new messages