So what happened to JHDLBits?

Antti Lukats wrote:
> <fpga_toys@yahoo.com> schrieb im Newsbeitrag
> > 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.

NO ... absolutely not.

EDIF has it's format publicly disclosed. There is no corresponding
document
for XDL ... so just producing XDL files with open source software would
use material under the licenses NDA in voilation of it's terms ...
specifically
disclosing the file format without permission, and having developed
competitive
software after express limitiations against such an act.

As soon as you emit library blocks in an XDL file, you would disclose
proprietary
interfaces to their library too, in volation of the NDA protecting
their
documentation at minimum, if not proprietary device information from
their
databases.

Actually, the license gives you no right to disclose any internal data
format,
except the resulting programming bit stream.

So, unless Xilinx decides to publicly release these file formats,
library definitions,
and related material ... open source development in support of Xilinx
FPGAs
is off limits.

We have large companies like Sun that do give back to the open source
community
in the form of IP for use in the community. Open Solaris, Open Office,
JAVA
are reasonable contributions in exchange for the wind fall that comes
from using
open source products in a commercial product. That is the standard of
conduct.

Not the highly restrictive licenses attached to every important Xilinx
software tools,
document, and interface.

<fpga_toys@yahoo.com> schrieb im Newsbeitrag 
news:1138289887.289407.179820@o13g2000cwo.googlegroups.com...
>
> Antti Lukats wrote:
>> <fpga_toys@yahoo.com> schrieb im Newsbeitrag
>> > 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.
>
> NO ... absolutely not.
>
> EDIF has it's format publicly disclosed. There is no corresponding
> document for XDL ... so just producing XDL files with open source software 
> would
> use material under the licenses NDA in voilation of it's terms ...
> specifically disclosing the file format without permission, and having 
> developed

well you really sound paranoid about the issue. If you do some tools that 
produce XDL and help xilinx to sell their silicon they will not go hunting 
you down. In how many different ways I have to say that?

If you start an open-source project that is totally useless but exposes all 
xilinx internals they will get upset. And with good cause.

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

Antti Lukats wrote:
> well you really sound paranoid about the issue. If you do some tools that
> produce XDL and help xilinx to sell their silicon they will not go hunting
> you down. In how many different ways I have to say that?

Or we could set the stage for another open source witch hunt, with
Xilinx
lawyers going after all the competitors and users asking for license
payments
like SCO.

The whole SCO wake up call is that we deal with IP rights properly, up
front,
or stay clear -- and don't expect everyone to be greatful when you
steal IP
from some big company.

In article <1138258290.422606.321110@g14g2000cwa.googlegroups.com>,
 <fpga_toys@yahoo.com> wrote:
>
>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.

I admit I mostly skimmed the JHDLBits thesis for relevent bits, but don't you 
think it was because JHDLBits got too heavily into the bitstream that the legal 
fury of Xilinx was roused?  (not to defend Xilinx in squashing the project; 
it does seem to be duplicitous to encourage a group and then squash them. I'm 
only looking for ways a similar fate can be avoided)  If development project 
sticks to XDL only and doesn't stray into bitstream issues do you think that 
Xilinx would make trouble for the participants?  Afterall, XDL files are clearly 
non-encrypted, human readable ASCII files.

>
>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.
>

Was anyone in the JDHLBits development group hit with financial penalties?

Phil

In article <dra3db$oc9$00$1@news.t-online.com>,
Antti Lukats <antti@openchip.org> wrote:
><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.

You say this based on discussions with Xilinx?  By what authority do you make 
this statement? (just checking)

>2) Xilinx can not make anyone or ar project to 'bit the dust' as you are 
>saing.

Well, if the JHDLBits folks were sent a cease and desist order from Xilinx 
Lawyers (have we established that to be true?) that would certainly have a 
chilling effect, no?  Open source developers and university students usually 
have no money to fight such an order so, in effect, it would kill the project.

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

But it sounds as if the JHDLBits folks developed something that had real value.  

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

Are you sure?  Then why isn't JHDLBits downloadable then?  While the papers are 
still available (they're academic papers which would be difficult to get 
removed) the code doesn't seem to be.

>
>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..
>

Which tool produces the .LL file?

>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.
>

We can hope.

Phil

In article <umzhjnnjz.fsf@trw.com>,
Martin Thompson  <martin.j.thompson@trw.com> wrote:
>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.

Good points.  But the tricky part is when we start parsing those files.  I 
would tend to think that since they are not encrypted that it's legal to parse 
them, but IP laws in recent years have gotten very restrictive (think DMCA) and 
who knows if Xilinx would interpret that as 'reverse engineering'.

>
>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).
>

I guess I'm starting to lean towards the idea of let's give it a try and see 
what happens.  

Phil

In article <drai9p$tru$00$1@news.t-online.com>,
Antti Lukats <antti@openchip.org> wrote:
><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
>

except that when you download WebPack you agree to a certain license.  One of 
the stipulations of that license is apparently non-disclosure and another 
prohibits reverse engineering.  

It's a tricky area these days...

Interesting that nobody from Xilinx has commented about what happened to 
JHDLBits, nor has anyone from there commented about open source tools using 
XDL.

Phil

Phil Tomson" <ptkwt@aracnet.com> schrieb im Newsbeitrag 
news:drb7dd11ie4@enews4.newsguy.com...
> In article <dra3db$oc9$00$1@news.t-online.com>,
> Antti Lukats <antti@openchip.org> wrote:
>><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.
>
> You say this based on discussions with Xilinx?  By what authority do you 
> make
> this statement? (just checking)
>
>>2) Xilinx can not make anyone or ar project to 'bit the dust' as you are
>>saing.
>
> Well, if the JHDLBits folks were sent a cease and desist order from Xilinx
> Lawyers (have we established that to be true?) that would certainly have a
> chilling effect, no?  Open source developers and university students 
> usually
> have no money to fight such an order so, in effect, it would kill the 
> project.
>
>>
>>If some entity developes something that has real value, then Xilinx will 
>>buy
>>that entity (not kill!).
>
> But it sounds as if the JHDLBits folks developed something that had real 
> value.
>
>>
>>If some open source project has no interest and no funding then it dies
>>eventually, all by itself. So that what has happened.
>
> Are you sure?  Then why isn't JHDLBits downloadable then?  While the 
> papers are
> still available (they're academic papers which would be difficult to get
> removed) the code doesn't seem to be.
>
>>
>>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..
>>
>
> Which tool produces the .LL file?
>
>>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.
>>
>
> We can hope.
>
> Phil

Hi Phil,

I replied based on my 'feeling' and best knowledges, but Ed McGettigan 
already answered
the XDL use issue in more details pretty much confirming what I have said, 
eg it is ok
to use/parse and modify/generate XDL

.LL is generated by bitgen it hold frame address and offset of RAM bits any 
flip flops
it is intended for readback verification, can be used to read back RAM 
contents
or register content, can also be used to initialize FF and RAMs or to change
the values during partial configuration

Antti

In article <draosp$f6u$00$1@news.t-online.com>,
Antti Lukats <antti@openchip.org> wrote:
><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.

But what's legally questionable is whether we can take an XDL file, generated 
by the Xilinx tools, parse it and then modify it and feed it back in.

>
>XDL is meant as interchangeable file format, like EDIF. 

But EDIF is a recognized standard while XDF could be construed by Xilinx to 
be an internally used file format.  The fact that it's human readable could be 
incidental.  The fact that XDL is human readable is potentially helpful 
(meaning that no decryption is required) but still there's doubt.  The IP 
laws in the US have really become quite draconian (and we're exporting those 
kinds of laws all over the world now ).

> You can use it if 
>you want. But you must of course be aware of the different license agreement 
>tems, sure.

Well, and one of those terms is that there be no derivative works.  If someone 
creates an XDL parser/generator and then uses that to create some sort of 
layout modifier that could easily be considered to be a derivative work, no?  
Now that's the letter of the law (or license agreement), but perhaps the intent 
is to prevent you from creating derivative works that could be used to program 
other non-Xilinx FPGAs?  Maybe Xilinx wouldn't mind if you develop tools 
around XDL that improve performance (as long as you stay away from the 
bitstream).  Some even seem to be suggesting in this thread that Xilinx has 
released XDL so that people will lose interest in messing with the bitstream 
and that they would be happy if people would develop tools around XDL - if so, 
it would be nice to hear that from Xilinx.

Phil

In article <drarmt$t2s$03$1@news.t-online.com>,
Antti Lukats <antti@openchip.org> wrote:
><fpga_toys@yahoo.com> schrieb im Newsbeitrag 
>news:1138289887.289407.179820@o13g2000cwo.googlegroups.com...
>>
>> Antti Lukats wrote:
>>> <fpga_toys@yahoo.com> schrieb im Newsbeitrag
>>> > 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.
>>
>> NO ... absolutely not.
>>
>> EDIF has it's format publicly disclosed. There is no corresponding
>> document for XDL ... so just producing XDL files with open source software 
>> would
>> use material under the licenses NDA in voilation of it's terms ...
>> specifically disclosing the file format without permission, and having 
>> developed
>
>well you really sound paranoid about the issue. 

Given the state of US IP law, being paranoid is understandable.  That's why I 
really wanted to have a good discussion about the issue before spending any 
time or effort on any open source tools like this...

>If you do some tools that 
>produce XDL and help xilinx to sell their silicon they will not go hunting 
>you down. In how many different ways I have to say that?

We can only hope that you're right.  However, the argument can be made that the 
JHDLBits folks created a suite of tools that could have helped sell silicon and 
apparenlty they were shut down.  Personally, I tend to think that Xilinx shut 
them down because they were getting too intimate with the bitstream and that 
working with XDL would be acceptable to Xilinx... but I'm not 100% convinced of 
that.  The way the laws are written Xilinx holds all the cards meaning that 
while they might initially smile upon your efforts (or at least ignore them) 
they could at any time change their mind.  Really, to some extent it doesn't 
even matter what a license agreement says; if a corporation sends lawyers after 
you and you're just a little guy, you're not going to be able to afford to press 
the issue - you'll immediately pull the software and never mention it again if 
you like living in a house and eating regularly ;-)

>
>If you start an open-source project that is totally useless but exposes all 
>xilinx internals they will get upset. And with good cause.

Sure, and that's certainly not the intent, but who knows how it could be 
interpreted?

Phil