So what happened to JHDLBits?

Ed McGettigan wrote:
> I take umbrage to your assertion that Xilinx is a leach and doesn't
> contribute back to the open source communities. Xilinx has been a
> contributing Corporate Patron of Free Software Foundation for many
> years now https://www.fsf.org/donate/patron/index_html funding many
> open source projects through the FSF with our donations.

The value of open source tools to Xilinx, as compared to implementing
your own GPL free tools and maintaining them is something in the ball
park of $10-30M in NRE and an additional $1-3M/yr to maintain them.
If Xilinx's contributions to open source are a significant fraction of
that
then clearly you have contributed back to the community.

> In addition we funded, supported and developed the Virtex-II Pro and
> Virtex-4 PowerPC405 ports that are the parent post of this thread and
> then push for their release into the official Linux 2.4.x and 2.6.x
> PowerPC trees so that everyone will have access to them easily.

That hardly counts, as the PPC port project existed before Xilinx
included
PPC's in the Pro's, and the Xilinx platform specific work is self
serving
to press your own hardware sales.

Nothing in your post, or any other Xilinx employees response, describes
why Xilinx allowed several man years of open source development in the
JHDLBits project to be simply squashed.

Let's just say that trashing a half dozen young engineers expectations
of contributing to the open source community with great pride in their
support of Xilinx product, is pretty damn low.  Umbrage in that would
be an understatement.

Ray Andraka wrote:
> Seems those who keep yelling for open bit streams aren't bothering to
> look at what is available, or try working with pieces.  They all seem to
> want full open bitstream without even understanding what all it entails
> to be able to successfully work with it.  You could do pretty much
> everything they seem to be looking to do within the existing XDL
> framework, and it gives the ability to use parts of the existing tools
> so you don't have to develop the entire tool chain from soup to nuts.
> Pick a piece of it and plug it into the existing tools.

It's not clear that XDL is in fact an official interface that will
avoid a
C&D order from Xilinx .... if it were completely documented, and the
parts data bases behind it completely documented, then your assertion
would be clearly true ... however, it isn't. Some reverse engineering
in unavoidable to use it fully, and that has clear restrictions from
Xilinx.

So, given that the JHDLBits project bit the dust at Xilinx's hands, and
it creaps into the same technology, and that Xilinx doesn't offically
bless
this interface to the degree of openess you suggest, let's just say it
would
be prudent to go a LOT slower in addopting it as the golden technology
you suggest.

fpga_toys@yahoo.com wrote:
> So, given that the JHDLBits project bit the dust at Xilinx's hands, and
> it creaps into the same technology, and that Xilinx doesn't offically
> bless
> this interface to the degree of openess you suggest, let's just say it
> would
> be prudent to go a LOT slower in addopting it as the golden technology
> you suggest.

Prudent to the degree of if you are young or have any assets, stay the
hell clear of it for open source projects - as you may not be able to
work
long enough in your life to pay off a judgement against you.

<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1138257624.935300.25730@o13g2000cwo.googlegroups.com...
>
> Ray Andraka wrote:
>> Seems those who keep yelling for open bit streams aren't bothering to
>> look at what is available, or try working with pieces.  They all seem to
>> want full open bitstream without even understanding what all it entails
>> to be able to successfully work with it.  You could do pretty much
>> everything they seem to be looking to do within the existing XDL
>> framework, and it gives the ability to use parts of the existing tools
>> so you don't have to develop the entire tool chain from soup to nuts.
>> Pick a piece of it and plug it into the existing tools.
>
> It's not clear that XDL is in fact an official interface that will
> avoid a
> C&D order from Xilinx .... if it were completely documented, and the
> parts data bases behind it completely documented, then your assertion
> would be clearly true ... however, it isn't. Some reverse engineering
> in unavoidable to use it fully, and that has clear restrictions from
> Xilinx.
>
> So, given that the JHDLBits project bit the dust at Xilinx's hands, and
> it creaps into the same technology, and that Xilinx doesn't offically
> bless this interface to the degree of openess you suggest, let's just say 
> it
> would be prudent to go a LOT slower in addopting it as the golden 
> technology
> you suggest.
>

1) XDL is official interface, any tools that parse and/or generate/modify 
XDL for any purpose are OK.
2) Xilinx can not make anyone or ar project to 'bit the dust' as you are 
saing.

If some entity developes something that has real value, then Xilinx will buy 
that entity (not kill!).

If some open source project has no interest and no funding then it dies 
eventually, all by itself. So that what has happened.

All RE needed can arranged to be done by some untouchable entity if it 
really comes to it.

But for Xilinx bitstream support there is a lot that can be done without any 
RE

first as Ray has also said the XDL contains pretty much 100% of the physcial 
design info.
the .LL files contains pretty much bit locations for purposes like post 
bitgen bitstream patching, etc..

there are so far no tools that actually do something useful with XDL and LL 
files, and I am sure Xilinx would welcome such open source projects.

-- 
Antti Lukats
http://www.xilant.com

On 25 Jan 2006 20:00:26 GMT, ptkwt@aracnet.com (Phil Tomson) wrote:

>In article <1138195188.897993.200480@g47g2000cwa.googlegroups.com>,
> <fpga_toys@yahoo.com> wrote:
>>
>>Phil Tomson wrote:
>>> But then someone brought up the fate of JHDLBits: apparently the prjoject was
>>> squashed by Xilinx.  Does anyone have any details about what happened?  

>>The status from the team a year ago was:
>>
>>     "we are still trying to figure out a schedule with Xilinx
>>      corporation on the release of the project. 
[...]
>>I've asked a several Xilinx staff about it both on and off the record.
>>On the record,
>>no reply. Off the record, "it will never happen".  The fine print in
>>Xilinx tools licenses
>>is a claim preventing reverse engineering of the chip layouts and
>>databases, even
>>though this is clearly visible to the user from several tools ranging
>>from the fpga
>>editor to the bit stream generator. 

>So barring any sort of 'creative' solution an XDL manipulation tool would 
>probably not be doable.

I suspect differently.

The key phrase from fpgatoys is "P&R to bitstream tool". Xilinx have
been ABSOLUTELY consistent on NOT making this public since before the
XC6200 came out - the openness of its bitstream was unique at the time.

Yet they DO supply XDL - and I don't think they ship it by mistake.
That was why my suggestion was to bypass the bitstream translation and
work entirely within what Xilinx do provide, instead of breaking the
(reasonable or otherwise) terms of the license agreement.

Sure there is a theoretical possibility that Xilinx could cease XDL ...
but IMO it's more likely to disappear "because nobody uses it" than for
the reverse reason. Its survival to date may indicate that it has
internal uses, such as tracing obscure NCD bugs.

>Perhaps it's possible if the open source tool would have no 'compilation of 
>database details'?  For example, you say that the information needed is 
>'clearly visible' from the various Xilinx tools themselves. 

No they aren't. FPGA editor isn't an electron microscope! It portrays a
representation of the routing, good enough to manipulate it and diagnose
and fix problems, but I think of it more like the London Underground map
than an Ordnance Survey (or USGS) map or a satellite photograph.

I don't see how compiling information at that level of detail would be a
problem.

>>They put a lot of energy into the project, then were told to
>>shutup and
>>walk away.
>
>Very poor form on Xilinx's part.

If "fpgatoys" spin is correct. But then, Xilinx lie about LUT counts,
mislead about power consumption, leach off the Open Source movement and
probably contribute to global warming too.

Or did Xilinx just stop funding the effort?

>Just as I said in the other thread: Corporations like control.  Xilinx, having 
>the majority share of the market, especially seems to like control.  Perhaps 
>one of the hungrier vendors would be willing to work with the open source 
>community.  If so, then in the longrun it's Xilinx's loss.

Yes, and as Jim Granville says, their customers like control too. So,
for an open source effort that wants to succeed, it's probably wise to
avoid threatening that control. 

I think Ray nailed it. 

If you take the viewpoint of rescuing the world from the evil Xilinx
Corporation and their closed bitstream format, they might not appreciate
your efforts. (does Austin really have a white cat?)

But if you actually use the tools they have made available, you may have
a better chance.

- Brian

fpga_toys@yahoo.com writes:

> Ray Andraka wrote:
> > Seems those who keep yelling for open bit streams aren't bothering to
> > look at what is available, or try working with pieces.  They all seem to
> > want full open bitstream without even understanding what all it entails
> > to be able to successfully work with it.  You could do pretty much
> > everything they seem to be looking to do within the existing XDL
> > framework, and it gives the ability to use parts of the existing tools
> > so you don't have to develop the entire tool chain from soup to nuts.
> > Pick a piece of it and plug it into the existing tools.
> 
> It's not clear that XDL is in fact an official interface that will
> avoid a
> C&D order from Xilinx .... if it were completely documented, and the
> parts data bases behind it completely documented, then your assertion
> would be clearly true ... however, it isn't. Some reverse engineering
> in unavoidable to use it fully, and that has clear restrictions from
> Xilinx.

It is documented - in the XDL files it produces.  The parts databases
are also documented in a fashion, as you can ask the XDL tool to dump
them for you in XDL format.

And XDL is used by parts of the Xilinx tool flow, so it's unlikely to
go away.

You should be able to solve all your placement problems with XDL and
then feed the results into the router (which will do a reasonable job
once it has a good placement).

Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt  
   

Martin Thompson wrote:
> fpga_toys@yahoo.com writes:
> > It's not clear that XDL is in fact an official interface that will
> > avoid a
> > C&D order from Xilinx .... if it were completely documented, and the
> > parts data bases behind it completely documented, then your assertion
> > would be clearly true ... however, it isn't. Some reverse engineering
> > in unavoidable to use it fully, and that has clear restrictions from
> > Xilinx.
>
> It is documented - in the XDL files it produces.  The parts databases
> are also documented in a fashion, as you can ask the XDL tool to dump
> them for you in XDL format.

To get those files requires assuming the license terms of
non-disclosure.
It remains a controlled and propietary format until such a time that
Xilinx
releases it in a public documents, outside those license terms.

<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1138281184.454302.70800@g14g2000cwa.googlegroups.com...
>
> Martin Thompson wrote:
>> fpga_toys@yahoo.com writes:
>> > It's not clear that XDL is in fact an official interface that will
>> > avoid a
>> > C&D order from Xilinx .... if it were completely documented, and the
>> > parts data bases behind it completely documented, then your assertion
>> > would be clearly true ... however, it isn't. Some reverse engineering
>> > in unavoidable to use it fully, and that has clear restrictions from
>> > Xilinx.
>>
>> It is documented - in the XDL files it produces.  The parts databases
>> are also documented in a fashion, as you can ask the XDL tool to dump
>> them for you in XDL format.
>
> To get those files requires assuming the license terms of
> non-disclosure.
> It remains a controlled and propietary format until such a time that
> Xilinx releases it in a public documents, outside those license terms.
>

there is no non-disclosure

just download ISE webpack and run XDL, there is no license above the 
standard webpack license

-- 
Antti Lukats
http://www.xilant.com 

Antti Lukats wrote:
> <fpga_toys@yahoo.com> schrieb im Newsbeitrag
> > To get those files requires assuming the license terms of
> > non-disclosure.
> > It remains a controlled and propietary format until such a time that
> > Xilinx releases it in a public documents, outside those license terms.
> >
>
> there is no non-disclosure
>
> just download ISE webpack and run XDL, there is no license above the
> standard webpack license

The standard ISE license contains:
"License. XILINX, Inc. ("XILINX") hereby grants you a nonexclusive
license to use the application, demonstration, and system software
included on this disk, diskette, tape or CD ROM, and related
documentation (the "Software") solely for your use in developing
designs for XILINX Programmable Logic devices. No right is granted
hereunder to use the Software, or its products, to develop designs for
non-XILINX devices. You own the media on which the Software is
recorded, but XILINX and its licensors retain title to the Software and
to any patents, copyrights, trade secrets and other intellectual
property rights therein."

Which clearly A) restricts your use of the software to activities
directly related to programming Xilinx devices, and B) claims full
rights to everything contined in the release. Implictly, derivative
works, that is development based on information disclosed directly or
indirectly in the release, is also restricted. ... AKA documenting
interfaces for open source use, or developing software derived from
this release (software, documentation, files, etc). This is further
clearified with:

"Restrictions. The Software contains copyrighted material, trade
secrets, and other proprietary
information. In order to protect them you may not decompile, reverse
engineer, disassemble, or otherwise reduce the Software to a
human-perceivable form. You agree not for any purpose to transmit the
Software or display the Software's object code on any computer screen
or to make any hard copy memory dumps of the Software's object code.
You may not modify or prepare derivative works of the Software in whole
or in part. You may not publish or disclose the results of any
benchmarking of the Software, or use such results for your own
competing software development activities, without the prior written
permission of Xilinx. You may not make any copies of the Software,
except to the extent necessary to be used on separate non-simultaneous
computers as permitted herein, and one copy of the Software in machine-
readable form for backup purposes only. You must reproduce on each copy
of the Software the copyright and any other proprietary legends that
were on the original copy of the Software."

Which clearly states the licensed material may not be used to prepare
derivative workes, or fairly broadly from the benchmarking provision,
perform competing software development activities based on analysis of
their product (AKA benchmarking).

These are clearly broad and inclusive terms which cover all aspects of
using derived and derivative IP based on materials contained in the
release.

AKA ... no open source access to disclosed interfaces inside this
material.

<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1138287854.181856.171000@g14g2000cwa.googlegroups.com...
>
> Antti Lukats wrote:
>> <fpga_toys@yahoo.com> schrieb im Newsbeitrag
>> > To get those files requires assuming the license terms of
>> > non-disclosure.
>> > It remains a controlled and propietary format until such a time that
>> > Xilinx releases it in a public documents, outside those license terms.
>> >
>>
>> there is no non-disclosure
>>
>> just download ISE webpack and run XDL, there is no license above the
>> standard webpack license
>
> The standard ISE license contains:
[snippped]

> These are clearly broad and inclusive terms which cover all aspects of
> using derived and derivative IP based on materials contained in the
> release.
>
> AKA ... no open source access to disclosed interfaces inside this
> material.
>

gosh, of course you can not use any interfaces or pieces of the xilinx 
licensed material. Thats clear.

XDL is just an readable ASCII file format. if your tool generates XDL then 
its ok, as long as you do not use any parts of materials from Xilinx.

XDL is meant as interchangeable file format, like EDIF. You can use it if 
you want. But you must of course be aware of the different license agreement 
tems, sure.



-- 
Antti Lukats
http://www.xilant.com