So what happened to JHDLBits?

In another thread we've been talking about creating some open source tools for parsing and manipulating XDL. The motivation being that since bitstreams are closed, working XDL might just be the next best thing.

But then someone brought up the fate of JHDLBits: apparently the prjoject was squashed by Xilinx. Does anyone have any details about what happened? If someone succeeded in developing an open source ecosystem of tools built around XDL, would that project also suffer the same fate? (It would be nice to know before investing much time and effort in developing tools around XDL)

I found a Master's thesis related to JHDLBits and it sounds eerily similar to the motivation for developing XDL tools, here's the title and abstract:

JHDLBits: An Open-Source Model for FPGA Design Automation Alexandra Vanessa Poetter Abstract Todays Field Programmable Gate Array (FPGA) research community could use an extensi- ble tool flow enabling designers to examine new algorithms and new methods of interacting with FPGA configurations. One such flow is JHDLBits, which integrates two prominent FPGA design environments: JHDL and JBits. JHDLBits offers the low-level access and control provided by JBits with the high-level structural circuit design of JHDL. Further- more, the JHDLBits flow provides greater control of resource manipulation, placement, and routing, and gives researchers a sandbox to explore advanced interactions with FPGA config- urations. This thesis presents the overall architecture of the open-source JHDLBits pro ject. Details are provided on how the core components JHDL, JBits3 for Virtex-II, the ADB connectivity database, and VTsim, a Virtex-II device simulator are linked together to provide an integrated design environment. Strategies and philosophies of the open source movement are also examined to successfully establish the support for and involvement of the FPGA research community throughout the JHDLBits open source endeavor.

The thesis can be found here:

formatting link

Phil

Reply to
Phil Tomson
Loading thread data ...

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. Xilinx funded the research and some parts of the project contained proprietary information, so we have been trying to come to an agreement. We are still hoping for a release sometime soon."

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. From what I have been told, any compilation of data base details into an open source equivalent P&R to bitstream tool as was done by the JHDLBits team will result in a C&D Order from Xilinx.

So, Xilinx let this team proceed, gained a lot of publicity from it as marketing collaterial, and then dashed the teams hopes of taking it open source. I doubt the team would have partnered with Xilinx had the outcome been clearly stated up front. They put a lot of energy into the project, then were told to shutup and walk away.

Much of what the FpgaC project needs to support compile, load, and go for Xilinx product is trapped in this project, with a clear warning from Xilinx to stay clear. The likely outcome is to focus on other vendors which are more willing to allow open source investment in RC technologies which support their products.

Reply to
fpga_toys

I should probably add that Xilinx leaches a hell of a lot of value off open source by using Linux as a host platform for it's tools, GCC at the main production compiler for PPC core software, GNU for the libraries for PPC, and Linux in several forms as host operating systems for it's product offerings.

It's probably worth writing Austin, Peter, and the other regular usenix posters from Xilinx and making it clear just how much Xilinx benefits from open source, the Xilinx market created by open source, and the developers which frequently volunteer their time supporting Xilinx open source use.

And then suggest that they take their thumb off the JHDLBits project, and start doing a better job of contributing back to the open source community. If that isn't enough to get their attention, maybe switching design wins to Altera and letting them know why.

Reply to
fpga_toys

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

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. So if a tool merely parsed the output of those tools to obtain the information needed it would not have any 'compilation of database details'. The problem of course is that it would make the open source tools dog slow: a design would have to be generated that would be sizeable enough to produce reports containing enough info, then after that it could start fixing the nets in the user's design. Possible, but probably not feasible.

Very poor form on Xilinx's part.

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.

Phil

Reply to
Phil Tomson

True.

It would take lots of letters to have any impact.

But is Altera any more open than Xilinx? I'm not sure that I've seen anything to suggest that they are.

Phil

Reply to
Phil Tomson

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

formatting link
funding many open source projects through the FSF with our donations.

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.

(Double post as the same comments where in another thread)

Ed McGettigan

--
Xilinx Inc.
Reply to
Ed McGettigan

Keep in mind that some of this 'paranoia' is not driven by Xilinx, but by their more secretive customers. If they see too much ability to reverse-spin the FGA designs, they imagine their secret sauce is more at risk - or that someone may be able to virus attack, or time-bomb, a FPGA, for example.

So they may not be able to give the lowest info, but it should be possible to create some middle format, that is able to be swallowed by P&R at great speed ( because it has very little to do ). That format would also be portable, so you are freed from tracking the device and even vendor increments.

-jg

Reply to
Jim Granville

Was JHDLBits reverse engineering the bitstream itself?

Isn't that sort of what XDL is supposed to be? If your theory is correct then Xilinx wouldn't have a problem with XDL based tools. It's really hard to guess what Xilinx's reaction would be to an open source XDL tool suite, but with the JDHLBits experience fresh in people's minds it's understandable why people are hesitant to invest much effort in such tools.

Phil

Reply to
Phil Tomson

It is called XDL. XDL is basically a readable ascii text version of the NCDs, and there are converters to and from NCD. It gives you hooks into the tool flow anywhere between translate's output and bitgen's input.

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.

Reply to
Ray Andraka

I guess to answer the question posted in the subject of this thread "What happened to JHDLBits?", in looking at the JHDLBits thesis a bit more, it would seem that maybe JHDLBits got too intimate with the bitstream and that put Xilinx in a litigious mood (the bitstream is the 3rd rail it seems). It may be that developing open source tools around XDL would be permited by Xilinx (I'd like to think so) so long as we avoid doing anything to or with the bitstream.

So let's forget about bitstreams and focus on XDL which is afterall non-encrypted ASCII.

"...drop that FPGA and step away from the bitstream, or we send in the Lawyers!"

Phil

Reply to
Phil Tomson

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.

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.

Reply to
fpga_toys

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.

Reply to
fpga_toys

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.

Reply to
fpga_toys

schrieb im Newsbeitrag news: snipped-for-privacy@o13g2000cwo.googlegroups.com...

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
Reply to
Antti Lukats

[...]

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.

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.

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?

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

Reply to
Brian Drummond

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
Reply to
Martin Thompson

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.

Reply to
fpga_toys

schrieb im Newsbeitrag news: snipped-for-privacy@g14g2000cwa.googlegroups.com...

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
Reply to
Antti Lukats

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.

Reply to
fpga_toys

schrieb im Newsbeitrag news: snipped-for-privacy@g14g2000cwa.googlegroups.com...

[snippped]

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
Reply to
Antti Lukats

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.