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

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:
> 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/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

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

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]]);}

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

2013=EB=85=84 4=EC=9B=94 5=EC=9D=BC =EA=B8=88=EC=9A=94=EC=9D=BC =EC=98=A4=
=EC=A0=84 7=EC=8B=9C 20=EB=B6=84 9=EC=B4=88 UTC+9, Mike Butts =EB=8B=98=EC=
=9D=98 =EB=A7=90:
> Hi Paul,
>=20
>=20
>=20
> It's a plain XC3020. I installed a 2001 Student Edition on my Win7 machin=
e, and it appears to run. All it needed was the license code that came with=
 the CD-ROM.=20
>=20
>=20
>=20
> I'm pretty sure XC3020 and XC3020A differ only in timing and the same bit=
file can work on both. Anyway I'll be finding out sometime soon and I'll po=
st how it goes.=20
>=20
> Thanks all!
>=20
>=20
>=20
>   --Mike

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

Thanks.
Wayne Hwang

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

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