Xilinx 2GB limit... something has to be done
Jay
be able to run the FPGA Editor. The program hits the 2GB memory limit
and quits. How did Xilinx test there code? I know that the memory
limit is imposed by Microsoft, and it is what it is, and there is no
changing that any time soon. So why can't Xilinx recode to use the
available memory space more efficiently or store data on the HD so at
least I can run (albeit more slowly).
And another thing, guess I can accept waiting 30 minutes to load a
database into a tool, but it seems crazy to have to wait another 30
minutes to exit without even saving just to get my memory back.
Jan Gray
news:d049f91b.02050...@posting.google.com...
> It appears that on a fully utilized XC2V6000, there is no solution to
> be able to run the FPGA Editor. The program hits the 2GB memory limit
> and quits. How did Xilinx test there code? I know that the memory
> limit is imposed by Microsoft, and it is what it is, and there is no
> changing that any time soon. So why can't Xilinx recode to use the
> available memory space more efficiently or store data on the HD so at
> least I can run (albeit more slowly).
Interesting!
If I recall correctly:
1. Some versions of Windows NT and follow ons allow 3 GB user space
addressing. There is a /3GB boot.ini flag. I don't know if Xilinx software
would have to be rebuilt to target it. This would be a reasonable interim
workaround if 2 GB is too confining.
2. Some versions of Windows 2000 and follow ons allow windowed access to
more than 4 GB of RAM per process. Shudder, too much like 1980's era bank
switching and overlays.
3. AMD Opteron and Intel Itanium are right around the corner. Both allow
flat 64 bit addressing, and both will be supported by a forthcoming Windows
XP. I bet you'll see Opteron systems for sale by 1Q03.
4. However, traditionally it has taken Xilinx a relatively long time
(relative to other ISVs) to adopt and support the latest Windows platforms.
For example, the Win32 PDC was in Dec'92 but Xilinx didn't support Win32
until several years later. So don't hold your breath.
.
On the other hand, IF devices grow too large to place and route in 2, 3, or
even 4 GB, Xilinx would certainly be highly motivated to:
1. continue to invest in more modular flows so you don't need to P&R the
whole design at one time;
2. ("" "" "" "" "" "" "" so you can employ P&R server farms -- not a memory
issue, just a design spin time issue)
3. adopt more memory efficient data structures, as you suggest;
4. make their code 64-bit safe NOW so they can ride the 64-bit Windows wave
just as soon as it becomes commercially available.
Oh yeah:
5. Xilinx ISE 4.2 implementation tools supposedly run on WINE on Red Hat
Linux 7.2. Xilinx has also announced plans to ship Linux-native tools in
2003. When they do, 64-bit Linux should also be ready to apply to this
problem.
[Disclaimer: this merely summarizes news articles that I have read.]
Jan Gray, Gray Research LLC
Tim
> And another thing, guess I can accept waiting 30 minutes to load a
> database into a tool, but it seems crazy to have to wait another 30
> minutes to exit without even saving just to get my memory back.
Close the design before exiting the program. Seems to be
at least 10 times faster than just exiting.
Hal Murray
>flat 64 bit addressing, and both will be supported by a forthcoming Windows
>XP. I bet you'll see Opteron systems for sale by 1Q03.
>4. make their code 64-bit safe NOW so they can ride the 64-bit Windows wave
>just as soon as it becomes commercially available.
>5. Xilinx ISE 4.2 implementation tools supposedly run on WINE on Red Hat
>Linux 7.2. Xilinx has also announced plans to ship Linux-native tools in
>2003. When they do, 64-bit Linux should also be ready to apply to this
>problem.
64 bit Linux is has been running fine for many years on Alphas
from Compaq/Digital. No excuse for not porting code now if they
are seriously interested.
SGI has 64 bit gear and they jumped on the Linux bandwagon a
while ago. I also see a sparc64 section in the Linux kernel
source tree. I haven't used either.
--
These are my opinions, not necessarily my employer's. I hate spam.
ham...@cloud.net.au
> It appears that on a fully utilized XC2V6000, there is no solution to
> be able to run the FPGA Editor. The program hits the 2GB memory limit
> and quits. How did Xilinx test there code? I know that the memory
How full is your design? I'm working on a 2V6000 design at the moment
(about 50% full) and haven't seen FPGA editor use anything like that
much RAM - PAR either, for that matter.
> And another thing, guess I can accept waiting 30 minutes to load a
> database into a tool, but it seems crazy to have to wait another 30
> minutes to exit without even saving just to get my memory back.
There's a Xilinx answer (at support.xilinx.com) on how to speed up
FPGA editor load time - I tried it the other day and it makes a
huge difference.
Hamish
--
Hamish Moffatt VK3SB <ham...@debian.org> <ham...@cloud.net.au>
Jan Gray
Correction (not that anyone else really cares): After some googling, I
recall there was a Win32 PDC (Professional Developer's Conference),
featuring NT, in SF in 7/92, and another Win32 PDC, featuring 'Chicago' (aka
Win95), in Anaheim in 12/93 (I attended that one).
Petter Gustad
> It appears that on a fully utilized XC2V6000, there is no solution to
> be able to run the FPGA Editor. The program hits the 2GB memory limit
> and quits. How did Xilinx test there code? I know that the memory
Maybe on a SUN UltraSPARC III under 64-bit Solaris :-)
I pray for a native ISE running under X86-64 Linux soon. Check out
http://www.x86-64.org.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.com
Keith R. Williams
newsma...@gustad.com says...
> kayr...@yahoo.com (Jay) writes:
>
> > It appears that on a fully utilized XC2V6000, there is no solution to
> > be able to run the FPGA Editor. The program hits the 2GB memory limit
> > and quits. How did Xilinx test there code? I know that the memory
>
> Maybe on a SUN UltraSPARC III under 64-bit Solaris :-)
AMD's Hammers will be out soon. I'd give them the inside odds on
success for the 64bit desktop.
> I pray for a native ISE running under X86-64 Linux soon. Check out
> http://www.x86-64.org.
I'd go there, though it's a PITA to have multiple systems just to
get things done.
----
Keith
Nicholas Weaver
Keith R. Williams <k...@attglobal.net> wrote:
>> Maybe on a SUN UltraSPARC III under 64-bit Solaris :-)
>
>AMD's Hammers will be out soon. I'd give them the inside odds on
>success for the 64bit desktop.
No bet. 2/1 says Hammer will win in the marketplace.
The performance on ideal code will probably be less than McKinley
(considerably so, the issue width on McKinley is wide, and a GOOD
compiler should be able to saturate or nearly saturate the 6 available
issue slots, but it needs a process shrink even before it is out in
the market), but hammer will be SO much cheaper, both by amortizing
cost over the consumer line, and the much smaller silicon real-estate,
and have better memory performance.
Also, McKinley is incredibly sensitive to bad code (much worse than
the out of order hammer). Since the 32 bit code can only be
considered bad code (8 x86 registers, 8 FP registers) which goes
through a hardware translator, the backwards compatability is slooow,
and there is nothing which can really be done about it.
Since the only reason why x86 survives is compatability and cost, why
would someone pay Ultrasparc prices for something which runs the old
code slowly?
Hammer, on the other hand, by using the same pipeline for 32 and 64
bit, essentially costs nothing (5% is AMDs claims) to add 64 bit
abilities, it has strong performance on both old and new code, has
better memory latency (by removing 2 chip crossings and reducing
memory access to <20 cycles + access time), and larger L1 caches.
--
Nicholas C. Weaver nwe...@cs.berkeley.edu
Petter Gustad
> Since the only reason why x86 survives is compatability and cost, why
> would someone pay Ultrasparc prices for something which runs the old
> code slowly?
Since it's the only 64-bit architecture where you can run the Xilinx
ISE 4.2i *today*... But hopefully that will change in the not so
distant future. Altera tools might be available on X86-64 before
Xilinx since they already have a native Linux version of Quartus II
2.0.
Austin Lesea
Please send me the entire design archive as the .zip file.
(aus...@xilinx.com)
I will send it to the software person to look into this.
You should be able to use 2GB for this part (we do here in the FPGA Lab).
Austin Lesea, Manager FPGA Lab
ham...@cloud.net.au
> Have you tried loading the design without the *.pcf file. The memory limit
> *shouldn't* be hit unless you have a very large number of constraints to
> annotate.
By the way, is there an advantage in having fpga_editor load in the PCF?
I've found it to be a bit of a nuisance on occasion - you can't delete
any location-locked I/Os, so you can't delete pins to replace them with
probes etc.