So what happened to JHDLBits?

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

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.

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.

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.

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

Phil

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

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.

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

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.

Which tool produces the .LL file?

We can hope.

Phil

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

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

Phil

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" schrieb im Newsbeitrag news: snipped-for-privacy@enews4.newsguy.com...

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

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.

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

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

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

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

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

Phil

It seems like the whole SCO vs IBM issue has now just devolved into an issue of SCO trying to stay alive as long as they can by lawsuits. While initially some in the open source community were afraid that SCO might have a case, now it's widely agreed that they never had a leg to stand on. It appears that SCO had no compelling products that would attract customers anymore, so instead of trying to compete they decided to litigate.

Phil

See another thread, Re: So Xilinx, is XDL and related libraries an available open source interface?

snipped-for-privacy@xilinx.com wrote : [part quoted here] "The XDL tool explicitly states that you are allowed to create tools that use the output of NCD2XDL or tools that create input for XDL2NCD. This use of course is restricted to use for Xilinx devices per the ISE 8.1i EULA."

So the answer rather depends on your precise/pedantic definition of open source.

Yes, XDL is an open specification, and you can create tools. No, you cannot target other silicon using XDL.

To many, that would be OK.

-jg

As one of the four people who worked on JHDLBits, perhaps I can clear up some of the misconceptions in this thread.

1. JHDLBits was indeed intended to be an open-source project, based upon JBits as the bitstream interface. There was never any actual or attempted reverse-engineering, because JBits already gave us the necessary bitstream access.
2. The development team was pretty green, and though we came up with some interesting stuff, the project was not robust (lack of understanding of how and when to use exceptions, lack of understanding of how to use public, private, and protected access, ...).
3. There was never any effort on the part of Xilinx, legal or otherwise, to squash the project. We simply got to the end of the funding agreement, had two people graduate, and another one eventually switch departments. That left me, and I was only involved on the side because of my familiarity with JBits and related tools, but I was busy working on my own research with its own unrelated funding.
4. JHDLBits could still be a worthwhile open-source project, although it's completely inactive at present, and if somebody with decent software engineering skills feels like bringing it up to snuff, your contribution would likely be welcomed with open arms.

Neil

Neil,

Thank you for setting the record straight. I am sorry that John Lawrence Bass (aka 'toys') has slandered the relationship, and the work you did.

I could not reveal the facts, as it would have violated your privacy and our agreeements with our research colleagues (which we respect).

Aust-snip-

for

around

Neil,

Thanks for clearing this up.

Is the source code available anywhere?

Phil

Thanks Neil, I certainly stand corrected and the Information I had been given last Feburary, including the quote in this threads second post from another JHDLBits team member, has obviously been superceeded with your assertion that Xilinx is no longer blocking the release ... good news. There are certainly people to help you finish this project, if indeed Xilinx has provided written permission to take it open source. Clearly the Xilinx staffer that told me that would never happen wasn't that clueful about Xilinx's willingness to relax it's license for your great project. And that does indeed signal an a different spin on Xilinx and open source that is substantially more positive for the future.

If you can transfer the sources to the the sourceforge repository, we will be very happy to help you pickup and complete the development. It might be useful to also include in that upload a copy of the Xilinx release letter.

I do appologize for the confusion created by the out of date information that was given to me, and I passed on.

John

Austin, a lof of these threads have been about open, accurate, and timely release of information, and the confusion that is created when that process fails. It would not have violated the privacy to simply state that Xilinx had in fact provided the JHDLBits team a release on such and such a date, which you should have done, rather than letting the discussion degrade.

Without that, older and inaccurate information is in fact, the most recient, and only information available.

Phil and I have already taken this discussion offline. If others are interested, I suspect that if you just want to see the code, you probably will not find it available. If you are interested in actively contributing to the project (and you understand that JHDLBits is simply a bridge between JHDL and JBits, along with the potential for supplemental JBits-based tools), I can make inquiries on your behalf.

Please note that I do not regularly monitor this group, so if you have further questions for me, please contact me directly.

Neil

This is probably the greatest news in a year, assuming all the components that Alex's papers described are made available ... especially the ADB and Fpga simulator projects.

The big question, is since it was layered on top of JBits, does this mean that JBits will now go main stream with ISE as an open source interface? If so, celebration time ... and many thanks to the Xilinx team :)

Have fun! John