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
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
Le 17/05/2012 10:44, RCIngham a écrit :
[...]I don't think so. I use this very often to output a variable, it works absolutely fine.
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
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
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
Le 17/05/2012 14:09, Andy a écrit :
I confirm that XST doesn't have any problem with it.
Nicolas
[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
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
Sorry, I missed the Foo vs Bar part of your orignal post. Which FPGA Family were you using?
Ed McGettigan
-- Xilinx Inc.
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.
This is targeting xc6slx9-tqg144-2. The original post has the .prj and .xst files as well as the .vhd.
Chris
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
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
Sounds like it is hitting Chris on the head too. :-)
Have something to add? Share your thoughts — no account required.
Ask the community — no account required