Which Xilinx version to use?
Thomas Heller
earlier) up to the newest ISE 5.1 (not sure I have 5.2 already).
Now I got my new machine with Windows XP, and I'm going to install
software.
But which version should I use?
I tried to install 3.1i because I've used that versionb before: the
installer crashed with problems in java.exe. Is this a known problem?
It seems the choice of the software version is somewhat limited, because
I probably have to support existing designs with XC4006E, Spartan,
Spartan XL, and Spartan2.
Is there a version of the Xilinx software which supports all of these
devices (I can probably give up the XC4006E, but I *have* to support all
the Spartan designs) and runs under Windows XP?
Thomas
Egbert Molenkamp
on Win2000 and XP. (When I remember a "JAVA" error)
See for a solution go to the following link (this works at least on an XP):
http://xup.msu.edu/solutions/xurc4.htm
Egbert Molenkamp
"Thomas Heller" <the...@python.net> schreef in bericht
news:smtv1c...@python.net...
Spam Hater 7
IIRC, ISE-4.2 is that last version that supports all of those devices.
I have noticed that ISE-5.2 is better for the devices that it
supports. So what I have done is to put 5.2 on my new machine, and
keep an old NT box running ISE-4.2.
I ran into a problem with the versions of simulation libraries once,
and I don't want to repeat that.
As long as I don't turn both of them on at the same time, I feel that
I am staying within the spirit of the license agreement.
If you include schematics in your design flow, you will probably need
to keep a copy of Foundation running.
$.02,
SH
Thomas Heller <the...@python.net> wrote in message news:<smtv1c...@python.net>...
Ray Andraka
4.2 on the windows2000 box. We have an NT box maintained with 3.3 and 4.2
installed on it, and a win2K box with 5.1 on it. I'm still using 3.3sp8 for
devices through VirtexE because the router does a considerably better job
than the later routers on floorplanned designs (do make sure you have the
newer speed files available from your FAE for 3.3 though, the timing in
speed files got worse going to 4.1).
Thomas Heller wrote:
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Benny Simonsen
Hey
There is no problem to install both ISE4 and ISE5 on the same mashine.
Just install it in different directories, and make sure to update the
XILINX enviroment variable and the PATH enviroment variable to the
directory you want to use.
I have installed each service pack in a differnent directory, so that
it is possible to try what the differences is between the different
versions.
Perhaps creating a startup script which sets both the XILINX and the
PATH variable.
Cross version usage don't give errors, but I don't think it is good.
If using executable from one version and the XILINX varaible is set to
another version gives ISE reporting one version number from the one
version and eq. XST and the other sub-programs reports a version
number from the other version.
--
Mvh Benny Simonsen
Brian Drummond
>I have a full shelf of Xilinx Software, from Foundation 2.1 (and maybe
>earlier) up to the newest ISE 5.1 (not sure I have 5.2 already).
>
>Now I got my new machine with Windows XP, and I'm going to install
>software.
>But which version should I use?
>
>I tried to install 3.1i because I've used that versionb before: the
>installer crashed with problems in java.exe. Is this a known problem?
I'm guessing you have a Pentium-IV.
I've just had problems with 3.3 Coregen on the same - the Java runtime
supplied (V1.17) crashes on a P-IV. Xilinx answers database pointed me
in this direction, in connection with problems with Chipscope (also uses
Java) but the "fix" was password protected, even the Xilinx support guy
couldn't access it!
Meanwhile we found the same fix (JRE version 1.18 - maybe later versions
too?) was available from SUN, I think http://java.sun.com and it fixed
the problem with Coregen, I imagine it would do the same for the
installer.
http://java.sun.com/products/archive/jdk/1.1.8_007/jre/index.html
(There may be operating system issues with XP/2000 too - my case was a
W98 one with an emergency motherboard replacement.)
>It seems the choice of the software version is somewhat limited, because
>I probably have to support existing designs with XC4006E, Spartan,
>Spartan XL, and Spartan2.
I've heard someone I respect say that 3.3 with SP8 still delivers the
best quality of results. (OK it was Ray, and he beat me to it! :-)
- Brian
Ray Andraka
provides a better QOR. 4.1 and later does seem to do better with unplaced
designs, which tells me that the new placer is perhaps better. The average
user, who does little if any floorplanning and does not typically push the
performance envelope will often see better results with the newer tools. Our
designs however, have invariably fared worse under the 4.1 and later routers
than they did in 3.3sp8.
Brian Drummond wrote:
> >It seems the choice of the software version is somewhat limited, because
> >I probably have to support existing designs with XC4006E, Spartan,
> >Spartan XL, and Spartan2.
>
> I've heard someone I respect say that 3.3 with SP8 still delivers the
> best quality of results. (OK it was Ray, and he beat me to it! :-)
>
> - Brian
--
Thomas Heller
> I should qualify that. For floorplanned designs, especially dense ones, 3.3
> provides a better QOR. 4.1 and later does seem to do better with unplaced
> designs, which tells me that the new placer is perhaps better. The average
> user, who does little if any floorplanning and does not typically push the
> performance envelope will often see better results with the newer tools. Our
> designs however, have invariably fared worse under the 4.1 and later routers
> than they did in 3.3sp8.
Thanks all you guys, there has been a lot of useful info in this thread.
Offtopic for this thread, any maybe a newbie question anyway (who finds
the silly bug I have here): This code snippet compiled fine with ISE
3.3i, but fails to compile with 4.1 (or was it 4.2?). I don't have the
exact error message handy anymore, but it didnt like the
TO_INTEGER(UNSIGNED(...)) construct:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.numeric_bit.ALL;
use IEEE.numeric_std.ALL;
library unisim;
use unisim.vcomponents.all;
...
type data_array is array(ndacs-1 downto 0) of std_logic_vector(nbits-1 downto 0);
signal din : data_array;
signal vrange : std_logic_vector(ndacs downto 0);
...
process(clk)
begin
if rising_edge(clk) then
if (wr_not = '0' and cs_not = '0') then
if (adr_latch = "00000000") then
data_reg(7 downto 0) <= data_bus;
elsif (adr_latch = "00000001") then
data_reg(15 downto 8) <= data_bus;
elsif (adr_latch = "00000010") then
data_reg(23 downto 16) <= data_bus;
elsif (adr_latch = "00000011") then
din(TO_INTEGER(UNSIGNED(data_bus(2 downto 0)))) <= data_reg(15 downto 0);
vrange(TO_INTEGER(UNSIGNED(data_bus(2 downto 0)))) <= data_bus(4);
end if;
end if;
end if;
end process;
Thanks for any help,
Thomas
Jan Decaluwe
>
> Ray Andraka <r...@andraka.com> writes:
>
> > I should qualify that. For floorplanned designs, especially dense ones, 3.3
> > provides a better QOR. 4.1 and later does seem to do better with unplaced
> > designs, which tells me that the new placer is perhaps better. The average
> > user, who does little if any floorplanning and does not typically push the
> > performance envelope will often see better results with the newer tools. Our
> > designs however, have invariably fared worse under the 4.1 and later routers
> > than they did in 3.3sp8.
>
> Thanks all you guys, there has been a lot of useful info in this thread.
>
> Offtopic for this thread, any maybe a newbie question anyway (who finds
> the silly bug I have here): This code snippet compiled fine with ISE
> 3.3i, but fails to compile with 4.1 (or was it 4.2?). I don't have the
> exact error message handy anymore, but it didnt like the
> TO_INTEGER(UNSIGNED(...)) construct:
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> use IEEE.numeric_bit.ALL;
> use IEEE.numeric_std.ALL;
Very old faq indeed ...
Thomas, the strange thing is not why this fails to compile,
but why it ever compiled ... these packages all do more or
less similar (but incompatible) things and are not all
standard despite the appearance. Only import a standard package
that you really need.
What you need should be IEEE.numeric_std.
Regards, Jan
--
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium
mailto:j...@jandecaluwe.com
http://jandecaluwe.com
Jonathan Bromley
> Offtopic for this thread, any maybe a newbie question anyway (who finds
> the silly bug I have here): This code snippet compiled fine with ISE
> 3.3i, but fails to compile with 4.1 (or was it 4.2?). I don't have the
> exact error message handy anymore, but it didnt like the
> TO_INTEGER(UNSIGNED(...)) construct:
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> use IEEE.numeric_bit.ALL;
> use IEEE.numeric_std.ALL;
Oooh, how many packages do you want, you greedy thing?
Seriously - this is completely mad. You ONLY need
std_logic_1164 and numeric_std. Your problem is that
numeric_std and std_logic_arith both define type UNSIGNED
(and a slew of operations thereon) and the conflicting
definitions simply become invisible. Anything that
compiled your code "successfully" is broken; the version
that complains has got it right.
Don't just chuck in every package you can think of. There
are very few situations for which you need more than simply
std_logic_1164 and numeric_std (or std_logic_arith, but not
both!). Don't use the ghastly hack std_logic_unsigned.
Use numeric_bit if you really must, but would you use
BIT for anything real? I doubt it. So don't bother
with numeric_bit either.
And... dare I say this... if you had compiled that lot
with a decent simulator, you would have discovered the
errors a lot sooner.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan...@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Thomas Heller
I was afraid it was something like that, that's why I posted the 'use'
lines also ;-)
With only std_logic_1164 and numeric_std, I get errors on the line
count <= count + 1;
where count is defined as
signal count : std_logic_vector(nbits-1 downto 0);
So I end up with this:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.numeric_std.ALL;
Does this get an OK from the experts?
>
> And... dare I say this... if you had compiled that lot
> with a decent simulator, you would have discovered the
> errors a lot sooner.
Well, not only did the code compile (with ISE 3.3i), but also
my chip worked (but this probably proves nothing).
Thanks,
Thomas
Jan Decaluwe
Not at all. std_logic_unsigned is the worst of all. First,
it is not a standard. Many years ago, it has been "virtually" put
in the IEEE library by some (irresponsible) guys at Synopsys -
soon to be followed by other CAD vendors, who put *different*
packages with the *same* name in that *same* library where they
should have stayed out. Given that those unacceptable actions cause
problems to this day, one would almost believe in a conspiracy
to kill VHDL.
Moreover, what std_logic_unsigned actually *does* is equally
despicable: it messes with the standard std_logic_vector, by
overloading it with operators that it was never intended to
support.
In short, you should not be able to count with std_logic_vector.
Use integer, signed or unsigned (from numeric_std), and convert
to std_logic_vector where necessary.
Jonathan Bromley
> I was afraid it was something like that, that's why I posted the 'use'
> lines also ;-)
[...]
> So I end up with this:
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> use IEEE.numeric_std.ALL;
>
> Does this get an OK from the experts?
See Jan's post - I agree with him, std_logic_unsigned is
a truly hideous hack invented by someone who was trying
to make VHDL look like Verilog. std_logic_arith, on the
other hand, is pretty much OK; but there is no point in
using it, because all its good features (and more) were
integrated into the formally-standardised numeric_std,
which is ALL YOU NEED for arithmetic operations!!!!!
> With only std_logic_1164 and numeric_std, I get errors on the line
> count <= count + 1;
> where count is defined as
> signal count : std_logic_vector(nbits-1 downto 0);
OK. This is the FAQ thing. Define
signal count: UNSIGNED(nbits-1 downto 0);
and then you are free to do
-- arithmetic operations are OK...
count <= count+1;
-- and you can compare UNSIGNED with integer, like this...
if count=9 then ...
-- and if you need to push "count" on to a std_logic_vector
-- signal, it's easy (if they are the same width!)...
some_std_logic_vector <= std_logic_vector(count);
-- and vice versa...
count <= UNSIGNED(some_std_logic_vector);
I think the comparison of UNSIGNED against integer may
possibly help tidy your code up, too:
> process (clk)
> begin
> if rising_edge(clk) then
> if (wr_not = '0' and cs_not = '0') then
> if (adr_latch = "00000000") then
becomes:
process (clk)
-- Just a temporary...
variable adr_val: UNSIGNED(7 downto 0);
begin
if rising_edge(clk) then
-- cast adr_latch to unsigned for later use
adr_val := unsigned(adr_latch);
-- now we can test "adr_val" as if it were a number
if (wr_not = '0') and cs_not = '0') then
if adr_val = 0 then ...
A little nicer, yes? Don't worry about what appears to
be an additional register "adr_val". Because it's ALWAYS
overwritten before it's used, the synthesis tool will turn
it into a bunch of wires directly connected to adr_latch.
> Well, not only did the code compile (with ISE 3.3i), but also
> my chip worked (but this probably proves nothing).
It proves that you are (a) lucky, and probably (b) careful;
and it strongly suggests that (c) when you come to do
something more complicated, you'll fall flat on your face
if you don't simulate it properly first. The whole point
of writing stuff in VHDL is that you can use the SAME code
as a simulation model and as your synthesisable design.
It's hardly worth the bother of writing all those
declarations if you can't use the simulator to check that
what you've written will work, BEFORE you turn it into
hardware.
Turn your back on those folk who tell you that you don't
need to simulate FPGAs because it's so easy to re-spin the
design. They are the snake in the grass, the Old Dragon
who "swinges the scaly horror of his folded tail".
(awe-inspiring imagery (c) J.Milton, circa 1665)