Xilinx 3s8000?

Jim, don't call it research. That word and "play" triggered this whole
barrage of Ron's favorite obscenities.
Peter

Peter Alfke wrote:

> Radarman, I agre with most of what you wrote, but I am not the boss
> here...
> One exception, though:
> " Why can't Xilinx allow me to use the latest ISE to
> target strange, esoteric FPGA's? Simply make it an optional component."
> Making the newest software compatible with XC3000 nd XC4000 would be a
> nightmare for our developers. They might declare it so difficult as to
> be virtually impossible. Backwards compatibility is a nightmare for any
> software developer (my son works at Apple R&D...)
> Otherwise you have some good ideas.
> It's just that our software developer have their plate full with urgent
> and vital projects, so that the things you mention often don't rise
> high enough.
> BTW, at work, I get some anusing comments about the insults I have to
> endure here. But they are so outlandish that they do not really hurt...
> Peter Alfke
> Peter Alfke

There are many degrees of compatible :

Easiest, is to first make sure they can co-exist - that's school-boy 
stuff.  ie No real excuse for getting that wrong...
[and I think this oops was radarman's main beef..?]

Next degree of compatible is to freeze the back end/command line tools, 
but keep export of XNF or whatever, so the older P&R tools can be fed 
from newer front ends.

To make the very newest SW compile to XC4000 is the wrong thing to do.

Not only is it the waste of resource you mention, but it is also poor 
version-control.
Someone doing maint changes, wants to use the _SAME_ tool chain it was 
created on.

-jg

In article <E9Q7g.233$227.179@fe04.lga>, Ron  <News5@spamex.com> wrote:

>The synthesizer reports a maximum frequency of 58MHz for the 64 bit 
>design, 16MHz for the 704 bit design, 12 MHz for the 1024 bit design "as 
>is" without any tweaking to improve the timing, so it should take about 
>1.1 microseconds to multiply two 64 bit numbers together, and 85 
>microseconds to multiply two 1024 bit numbers together.

The unoptimised build of gmp on this bog-standard Athlon X2 4400+
system takes ten microseconds for a 1024x1024->2048 multiply; and
there are two processor cores working independently.

I really think you haven't looked enough into what can be done in
software before jumping to hardware; gmp-ecm is in the public domain,
and Bruce Dodson runs it full-time on a 120-node Opteron cluster at
LeHigh university.

Tom

Tom-

> I really think you haven't looked enough into what can be done in
> software before jumping to hardware; gmp-ecm is in the public domain,
> and Bruce Dodson runs it full-time on a 120-node Opteron cluster at
> LeHigh university.

Haha, be careful of what you suggest.  Now Ron will need a
complimentary Opteron cluster from AMD :-)

-Jeff

Tom-

> I really think you haven't looked enough into what can be done in
> software before jumping to hardware; gmp-ecm is in the public domain,
> and Bruce Dodson runs it full-time on a 120-node Opteron cluster at
> LeHigh university.

Haha, be careful of what you suggest.  Now Ron will need a
complimentary Opteron cluster from AMD :-)

-Jeff

Agreed - my primary gripe is that the older versions don't play well
with a newer version installed and vice-versa.

Right now, my copy of 7.1 is unusable - and I'll have to get an admin
to clean it up to the point where it is usable again. I can manually
make it mostly usable by altering the system environment variables -
but that's a bit of a pain. To top it off, the 4.2 install doesn't
quite work properly either - probably for the same reason. It seems to
go through mapping and PAR OK, but I have to create the downloadables
on another system. We fought for a week with every part of the
toolchain until we switched to another workstation to create the
bitstream files - no errors, just corrupt binaries.

When I'm more or less done maintaining the old design, I'm probably
going to just wipe both off, and install the latest version again.

Radarman-

> We fought for a week with every part of the
> toolchain until we switched to another workstation to create the
> bitstream files - no errors, just corrupt binaries.

I don't understand the struggle.  You are violating basic usage
principles of ISE.  Never a) uninstall and re-install, or b) install a
new version on the same machine as an earlier working version.  The
only thing permitted on any given machine is service pack upgrades
within a version.  Yes that leaves you with the "5.1 machine", the "6.1
machine", etc. but that's the rule.  Your FAE should have told you
that; it's all we've ever heard since 1999 and several different FAEs.

-Jeff

Jeff Brower wrote:
> Tom-
>
> > I really think you haven't looked enough into what can be done in
> > software before jumping to hardware; gmp-ecm is in the public domain,
> > and Bruce Dodson runs it full-time on a 120-node Opteron cluster at
> > LeHigh university.
>
> Haha, be careful of what you suggest.  Now Ron will need a
> complimentary Opteron cluster from AMD :-)
>
> -Jeff

haha, I wouldn't mind one as well. Perhaps it will make my games run
smoother :).

Hi Ron,

Are you attempting a 100% hardware solution or are you doing a mix of
both hardware and PC software?
(Forgive me if this question has already been answered).

-Isaac

radarman wrote:
> Agreed - my primary gripe is that the older versions don't play well
> with a newer version installed and vice-versa.
>
> Right now, my copy of 7.1 is unusable - and I'll have to get an admin
> to clean it up to the point where it is usable again. I can manually
> make it mostly usable by altering the system environment variables -
> but that's a bit of a pain. To top it off, the 4.2 install doesn't
> quite work properly either - probably for the same reason. It seems to
> go through mapping and PAR OK, but I have to create the downloadables
> on another system. We fought for a week with every part of the
> toolchain until we switched to another workstation to create the
> bitstream files - no errors, just corrupt binaries.
>
> When I'm more or less done maintaining the old design, I'm probably
> going to just wipe both off, and install the latest version again.

Would a VM like VMWare or VPC do the trick, keep your OS with ISE
version installed in different virtual boxes. As long as only one runs
all the machine resources are available to that VM guest, whether its
Linux or Windows.

John Jakson

Isaac Bosompem wrote:
> Are you attempting a 100% hardware solution or are you doing a mix of
> both hardware and PC software?

Hi Isaac.

Yes, as I mentioned to Tom elsewhere in this thread, I have written a 
100% Verilog implementation of ECM (as well as Fermat's method and 
Pollard-Rho). It's runs completely standalone and is not connected to 
anything except power. It would display the answer (if found) on the 
development board's LCD display.

I have no objection to using an FPGA as an accelerator for a program 
running on a conventional computer, but was hoping to fit the entire 
thing (ECM) on one or more FPGA development boards because that keeps 
things fast and simple. For me, it's at least as easy to code in Verilog 
as it is in a typical assembly language, so I see no reason to clutter 
things up by going off-board or adding a micro-CPU core.

My reasoning is that eventually (hopefully within my lifetime, ha!) 
FPGA's will become huge and cheap, and I'm hoping that the LUT count of 
FPGAs increase faster than the performance of traditional computers. 
That hope may not be justified of course, because some of the same type 
of technology is used in both CPUs and FPGAs; however, there is no 
chance that I'll ever be able to afford a cluster of Opterons, but if I 
can find a way around the exorbitant prices FPGA vendors charge for 
proprietary software design tools (that can only be used with their own 
products no less), I could probably afford a fairly high performance FPGA.

In any case, writing ECM in Verilog has been fun and I've learned a lot 
about Verilog. I now have a working Verilog ECM design, and I'll spend 
the time until development s/w gets cheap enough for me to afford by 
tweaking and improving the design. I've been forced to slow my design 
down to a crawl in order to try to get it to fit into something I can 
afford, but whenever FPGA's and the requisite design s/w become 
plentiful and cheap, I hope to be able to take full advantage of all the 
opportunities for parallelization and pipelining that ECM offers.

Regards,

Ron