Xilinx tools for XC3020???

M

Mike Butts

Guest
I've got a 20-year-old Xilinx XC3020 development board. I think it would be fun to fire it up and bring it to the 20th anniversary FCCM in Seattle next month. (http://fccm.org/2013/)

I don't see XC3000-series supported on even the oldest archived ISE at xilinx.com. Anyone know where I can find some tools for this old chip? It has 64 CLBs and 256 flip-flops! Maybe one of you folks at Xilinx? Thanks!

--Mike
 
On 3/25/2013 7:04 PM, Mike Butts wrote:
I've got a 20-year-old Xilinx XC3020 development board. I think it would be fun to fire it up and bring it to the 20th anniversary FCCM in Seattle next month. (http://fccm.org/2013/)

I don't see XC3000-series supported on even the oldest archived ISE at xilinx.com. Anyone know where I can find some tools for this old chip? It has 64 CLBs and 256 flip-flops! Maybe one of you folks at Xilinx? Thanks!

--Mike
A major problem with the really old Xilinx tools (Alliance and
Foundation) is that Xilinx did not provide the front-end
(synthesis or schematics). In the alliance version you
had to buy a third-party tool like ViewLogic to get a
front end. Foundation added an Aldec front-end, but then
there was a falling out between Xilinx and Aldec so Xilinx
is no longer able to supply those tools (although for
people who already had them they still run - I have Foundation
4.1i to support really old designs, but not as old as the XC3000
series).

I'm not sure what you could get running in a chip that small
that might impress anyone at FCCM, unless it's just the
antiquity of the thing. In any case, unless you find
someone who still has a running copy of the old tools,
you'll spend way too much to get the development environment.

-- Gabor
 
On 3/25/2013 8:04 PM, Mike Butts wrote:
I've got a 20-year-old Xilinx XC3020 development board. I think it would be fun to fire it up and bring it to the 20th anniversary FCCM in Seattle next month. (http://fccm.org/2013/)

I don't see XC3000-series supported on even the oldest archived ISE at xilinx.com. Anyone know where I can find some tools for this old chip? It has 64 CLBs and 256 flip-flops! Maybe one of you folks at Xilinx? Thanks!

--Mike
I have a set of tools from the 1999 time frame that might just do what
you want. It has a parallel port key which is still around somewhere.
I don't have the nerve to try to get this working on anything remotely
current. If you have a copy of Windows 98 running on a ISA bus machine
somewhere it might do it for you. But that will be the problem, finding
a machine that will still run the software. I guess it is possible it
might run on a current machine... if you have the floppy drives for
it... lol I'm not sure if the media is floppy or CD, at that time it
was a toss, even for larger distributions I think.

If you want it, I might just box it up and send it all to you. I am a
junk collector, but I know I'll never fire that up again.

--

Rick
 
Thanks Rick and Gabor,

You reminded me to dig through my dusty old CD-ROMs. I found two sets of Xilinx Student Edition (predecessor to WebPack), one from 1999, the other from 2001, both with notes that might include the codes required. I'll see if they work on my PC.

As for schematic or synthesis tools, no need - back then I got quite comfortable writing xnf files from scratch and running map/par/bitgen from the command line.

Of course all anybody could fit in 64 LUTs is a demo toy like random dice or the infamous traffic light controller. It's a reminder of how FPGAs have grown with Moore's Law in 20 years, from 1K gates to 10M gates!
 
On 27.03.2013 01:00, rickman wrote:
I don't have the nerve to try to get this working on anything remotely
current.
Virtual machines do a very good job here. I have ISE 4.1 running on a
Windows XP virtual machine here to support Spartan XL.

It's a good thing nobody asked for any changes on the XC5206 Design that
we still sell. It's not even VHDL or Verilog. Rumor has it someone here
has a Windows 3.1 machine (Hardware, not virtual) with the tools to
support it somewhere. But I'm not going wake sleeping dogs here.

- Philip
--
Rule 15: Know your way out (Zombieland)
 
On 3/25/2013 7:04 PM, Mike Butts wrote:
I've got a 20-year-old Xilinx XC3020 development board. I think it would be fun to fire it up and bring it to the 20th anniversary FCCM in Seattle next month. (http://fccm.org/2013/)

I don't see XC3000-series supported on even the oldest archived ISE at xilinx.com. Anyone know where I can find some tools for this old chip? It has 64 CLBs and 256 flip-flops! Maybe one of you folks at Xilinx? Thanks!

--Mike


Is this a 'plain' XC3020 or the XC3020A or 'L'? I have a Foundation
Express 1.5 loaded up on a Win 98 VM running under VMware Workstation 8
on a Win 7 host.

Just for 'fun' I coded up an 8-bit counter and was able to push the
design all the way through the flow and generate a bit file.

Unfortunately F1.5 doesn't support the original XC3000 family, only the
later 'A' and 'L' revisions.

That's too bad because I just found several XC3042's, 3020's, 2018's,
2064's, and some 95108's in my collection. What kind of retro project
could be built with that collection of logic?

I'm certain that I have earlier versions of the Xilinx somewhere that
will support that old stuff. All of the licenses back then were locked
to a hard drive serial number, which are easy to change when moving to a
new pc - real or virtual.

--Paul
 
Hi Paul,

It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it appears to run. All it needed was the license code that came with the CD-ROM.

I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work on both. Anyway I'll be finding out sometime soon and I'll post how it goes.
Thanks all!

--Mike
 
2013년 4월 5일 금요일 오전 7시 20분 9초 UTC+9, Mike Butts 님의 말:
Hi Paul,



It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it appears to run. All it needed was the license code that came with the CD-ROM.



I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work on both. Anyway I'll be finding out sometime soon and I'll post how it goes.

Thanks all!



--Mike

Hi Mike,
Do you have any progress?
I am very interesting your work...^^

Thanks.
Wayne Hwang
 
On 4/4/2013 6:20 PM, Mike Butts wrote:
Hi Paul,

It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it appears to run. All it needed was the license code that came with the CD-ROM.

I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work on both. Anyway I'll be finding out sometime soon and I'll post how it goes.
Thanks all!

I take it you are on your way. I found my old Xilinx software *and*
what I think are the dongles for it, a couple three of them. I believe
the oldest version is Foundation 1.4, but I'm not sure as I seem to have
left the box will it all at my other place.

I actually promised this to someone so I need to find his email and tell
him I can ship it if he is still interested.

I also have a set of floppies with ViewLogic (if I remember the right
name)... they *are* 3.5 inch floppies, not 5 1/4. :p

--

Rick
 
In article <l3i913$1af$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 4/4/2013 6:20 PM, Mike Butts wrote:
Hi Paul,

It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it
appears to run. All it needed was the license code that came with the CD-ROM.

I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work
on both. Anyway I'll be finding out sometime soon and I'll post how it goes.
Thanks all!

I take it you are on your way. I found my old Xilinx software *and*
what I think are the dongles for it, a couple three of them. I believe
the oldest version is Foundation 1.4, but I'm not sure as I seem to have
left the box will it all at my other place.

I can confirm that Xilinx XACT runs on Windows-XP (with the dongle). You
can hand-edit your XC2064s :)

Also, I remember that early versions of Foundation were tied to the
partition serial number in the MBR (which you can easily change with DOS
"debug" command). I mean the first versions which finally got rid of the
dongle.

--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
 
Joseph H Allen wrote:
In article <l3i913$1af$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote:
On 4/4/2013 6:20 PM, Mike Butts wrote:
Hi Paul,

It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machine, and it
appears to run. All it needed was the license code that came with the CD-ROM.

I'm pretty sure XC3020 and XC3020A differ only in timing and the same bitfile can work
on both. Anyway I'll be finding out sometime soon and I'll post how it goes.
Thanks all!

I take it you are on your way. I found my old Xilinx software *and*
what I think are the dongles for it, a couple three of them. I believe
the oldest version is Foundation 1.4, but I'm not sure as I seem to have
left the box will it all at my other place.

I can confirm that Xilinx XACT runs on Windows-XP (with the dongle). You
can hand-edit your XC2064s :)

Also, I remember that early versions of Foundation were tied to the
partition serial number in the MBR (which you can easily change with DOS
"debug" command). I mean the first versions which finally got rid of the
dongle.
I've got a copy of Foundation 1.3 (this one was also called XACT Step
Foundation) on my bookshelf. I think that 2.1 was out by the time I
actually started using Xilinx parts. I still have ViewDraw running on
Windows XP as well as Foundation 4.1i. I think I was running NT 4.0
when I started with Xilinx tools. By then the oldest family I used was
the XC4000 series and very soon moved on to Spartan, SpartanXL and
Virtex.

My copy of Foundation 4.1i does not support XC3000 series, but since
there were options to include individual families when you install it
I am not sure if that means that 4.1i doesn't support XC3000 or if I
simply didn't install that in order to save some disk space at a time
when a large hard drive was 5 GB.

Since I started using Foundation, the license has been tied to the
hard drive serial number, which is easily changed, and probably
one of the reasons that Aldec sued Xilinx for delivering uncounted
seats.

The most recent Xilinx product licenses are tied to the MAC address
which can also be changed on most add-in card based Ethernet
controllers. Xilinx is also willing to re-target your license to
a new PC, so there are many ways to cheat the seat count.

--
Gabor
 
On 10/15/2013 2:57 PM, GaborSzakacs wrote:
The most recent Xilinx product licenses are tied to the MAC address
which can also be changed on most add-in card based Ethernet
controllers. Xilinx is also willing to re-target your license to
a new PC, so there are many ways to cheat the seat count.

I am a one man company, so I never have incentive to "cheat the seat
count". But this thread is exactly the issue I am concerned about with
licensed software. Will it be supported some years down the road when I
need it for an update? If it were FOSS, I would know the answer. But
so far I have found commercial software to be tied to the bucks it can
generate for the developers in the future, not the bucks you have paid
in the past.

This is the one reason I can see in favor of pushing for FOSS FPGA
software. But unfortunately the ones pushing are a very small force
compared to the overall market so that they have *no* influence in the
direction of FPGA development software... at least in terms of being
supported by the FPGA vendors.

--

Rick
 
rickman wrote:
I am a one man company, so I never have incentive to "cheat the seat
count". But this thread is exactly the issue I am concerned about with
licensed software. Will it be supported some years down the road when I
need it for an update?
I think this problem has been simplified by the advancements in
virtualization in recent years. At the company where I used to work, we
had virtual machines with old Windows releases and old tools versions,
and someone was clever enough to migrate the licenses for the old tools
to those VMs before it was too late. The VMs themselves you can just
copy from one PC to another if you upgrade your hardware. They had some
issues with old parallel port dongles (since which PC has a parallel
port nowadays?), but there's add-pon cards for that. So at least there's
a working version of all the tools needed for older projects.

This is the one reason I can see in favor of pushing for FOSS FPGA
software. But unfortunately the ones pushing are a very small force
compared to the overall market so that they have *no* influence in the
direction of FPGA development software... at least in terms of being
supported by the FPGA vendors.
Exactly. I personally don't think this is ever going to go anywhere.
Even if there was enough manpower to design a decent toolset from the
ground up (which there isn't, since the people who have the capabilities
and know-how usually work for one of the vendors), vendors would have to
disclose too many architecture internals and such, which is not going to
happen (maybe they'd release that info for FPGA families that have been
out of production for years but not current ones).

I can imagine a University putting something together, but something
like that usually stays at the 0.0011alpha release state forever once
the PhDs it's based on are finished.

In general, for a project this size and type FOSS rarely works, IMHO. It
can work if the community can get an existing code base and improve it
(like it happened for Mozilla and OpenOffice), but not if it's to be a
project of this size and started from the ground up. Especially if it's
something that doesn't "interest" a lot of people. After all, this is a
niche (compared to something like the Gimp which potentially has
millions and millions of users), so there's just not that many people
likely to participate in the first place. This wouldn't be something
that everyone(TM) uses, and it's way too big for a single person or
small group of people to make any useful progress.

So, no, I don't think OS EDA tools are ever going to happen. At least
not something really useful... Unless one of the vendors decides to
release the source code for their tools. But why should they?

CU,
Sean
 
On 10/16/2013 3:33 AM, Sean Durkin wrote:
rickman wrote:
I am a one man company, so I never have incentive to "cheat the seat
count". But this thread is exactly the issue I am concerned about with
licensed software. Will it be supported some years down the road when I
need it for an update?
I think this problem has been simplified by the advancements in
virtualization in recent years. At the company where I used to work, we
had virtual machines with old Windows releases and old tools versions,
and someone was clever enough to migrate the licenses for the old tools
to those VMs before it was too late. The VMs themselves you can just
copy from one PC to another if you upgrade your hardware. They had some
issues with old parallel port dongles (since which PC has a parallel
port nowadays?), but there's add-pon cards for that. So at least there's
a working version of all the tools needed for older projects.

You are talking about one particular licensing scheme for one, very old
product. The licenses used on newer software work off of a software key
that is tied to some aspect of your PC but more importantly, must be
renewed each year regardless. If they stop renewing the license, you
are stuck.


This is the one reason I can see in favor of pushing for FOSS FPGA
software. But unfortunately the ones pushing are a very small force
compared to the overall market so that they have *no* influence in the
direction of FPGA development software... at least in terms of being
supported by the FPGA vendors.
Exactly. I personally don't think this is ever going to go anywhere.
Even if there was enough manpower to design a decent toolset from the
ground up (which there isn't, since the people who have the capabilities
and know-how usually work for one of the vendors), vendors would have to
disclose too many architecture internals and such, which is not going to
happen (maybe they'd release that info for FPGA families that have been
out of production for years but not current ones).

It is *not* a matter of designing a *decent* toolset. The problem is
the FPGA vendors don't release the information required to use their
devices without their proprietary software. You simply *can't* roll
your own FPGA development package end to end. It would be like writing
a compiler for a CPU with no info on the instruction set.


I can imagine a University putting something together, but something
like that usually stays at the 0.0011alpha release state forever once
the PhDs it's based on are finished.

There *are* FOSS HDL synthesis and simulation tools. I don't know, but
I doubt there are FOSS place and route tools or timing analysis. The
part that you just can't do without a *huge* reverse engineering effort
is generating the bit stream file.


In general, for a project this size and type FOSS rarely works, IMHO. It
can work if the community can get an existing code base and improve it
(like it happened for Mozilla and OpenOffice), but not if it's to be a
project of this size and started from the ground up. Especially if it's
something that doesn't "interest" a lot of people. After all, this is a
niche (compared to something like the Gimp which potentially has
millions and millions of users), so there's just not that many people
likely to participate in the first place. This wouldn't be something
that everyone(TM) uses, and it's way too big for a single person or
small group of people to make any useful progress.

So, no, I don't think OS EDA tools are ever going to happen. At least
not something really useful... Unless one of the vendors decides to
release the source code for their tools. But why should they?

*That's* a bit extreme. There are ***tons*** of FOSS EDA tools
available, as I mentioned, even HDL tools. It is just the final part
that requires intimate knowledge of the chips that is not so feasible to
develop.


--

Rick
 
rickman wrote:
You are talking about one particular licensing scheme for one, very old
product. The licenses used on newer software work off of a software key
that is tied to some aspect of your PC but more importantly, must be
renewed each year regardless. If they stop renewing the license, you
are stuck.
You are right about that. But in all the cases I am familiar with you
could switch to perpetual licenses when support was dropped (which you
were informed of in a timely manner). The main problem was then having a
machine the tools still run on.

It is *not* a matter of designing a *decent* toolset. The problem is
the FPGA vendors don't release the information required to use their
devices without their proprietary software. You simply *can't* roll
your own FPGA development package end to end. It would be like writing
a compiler for a CPU with no info on the instruction set.
That is what I was saying. Still there's more to writing a USABLE
toolset than just having the necessary information. I doubt that even if
Xilinx would release all the specs, we'd ever get a DECENT, usable FOSS
toolset. That kind of complex work requires coordinated effort,
something that obviously not even the vendors with dedicated, big
development teams can muster, let alone keep up to date with the
ever-evolving chip technology. That is not the kind of project suitable
to the OSS "community"-based design flow (there's exceptions, see below).

There *are* FOSS HDL synthesis and simulation tools. I don't know, but
I doubt there are FOSS place and route tools or timing analysis. The
part that you just can't do without a *huge* reverse engineering effort
is generating the bit stream file.
Not that I'm aware of, except maybe some highly experimental stuff based
on obsolete parts. In other words: useless, except for academic fiddling.

*That's* a bit extreme. There are ***tons*** of FOSS EDA tools
available, as I mentioned, even HDL tools.
And that's exactly the problem. Tons of different tools, but nothing
that is really useful (well, ghdl maybe... and if you wanna count Emacs
VHDL mode as an EDA tool...).
IMHO that's a general problem of FOSS. You can find some tool for almost
EVERYTHING, but usually it stays in the state where it does exactly what
the person who started it needed at one point, but nothing else. Then
another person, who isn't content with what's available, starts another
project, and so on. In the end you have a dozen tools that satisfy the
needs of their respective creators, but are more or less useless to the
rest of humankind. So if you don't have the time or know-how to improve
the tools yourself, you're screwed. But you can't complain, since you
can't look a gift hourse in the mouth...

I've been using Linux for 15 years, and of course a lot of FOSS, and
there's wonderful software out there far surpassing anything
commercially available. But IMHO OSS really only works well in these cases:
1. small tools that can be handled by one enthusiastic person or a small
group of people in their spare time
2. tools/services that big companies are pushing (like Red Hat or
Google), meaning they put a decent-sized development team on it and pay
it to work on that
3. projects that are based on an existing commercial product's source
code (see OpenOffice and the like), or were developed commercially and
then released to the public for whatever reason
4. projects that have many, many (potential) users and a lot of paid
professional people chipping in (like the Linux kernel, the GCC suite,
Gnome or KDE)

EDA tools fit NONE of the above.

And in cases like that you typically end up with tons of half-baked
tools. As long as vendors provide free licenses for their tools at least
for hobbyist use, there's really no incentive for hobbyists to invest
their time and work in FOSS EDA tools. I'm saying hobbyists, since the
pros work for one of the vendors anyway and/or don't have the need for
FOSS because they have licenses for the commercial tools. And all of
this applies even if all the required information was available, which
it is not. On projects like that you never seem to see any real
progress, because a) there's not enough manpower, b) there's not enough
incentive and c) they soon hit the wall where they can't get the
information they need.

You are of course right that it would be nice to have FOSS tools to rely
on for eternity, but as you said the number of people really needing
that is small, way too small to get anything accomplished, really. So
I'm sticking with what I said before: I don't see it happening, ever.
Not for a toolchain for the complete flow, and one that goes beyond
cryptic command-line tools that work in only 30% of applications.

cu,
Sean
 

Welcome to EDABoard.com

Sponsor

Back
Top