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:
 http://rubyurl.com/wvm

Phil

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

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.

fpga_toys@yahoo.com wrote:
> 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.


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.

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

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

Very poor form on Xilinx's part.

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

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

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

True.

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

It would take lots of letters to have any impact.

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

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

Phil

fpga_toys@yahoo.com wrote:

 > I should probably note 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 as
 > 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 usenet
 > 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.
 >

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.

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.

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

  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

In article <43d81e83@clear.net.nz>,
Jim Granville  <no.spam@designtools.co.nz> wrote:
>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?  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)
>> 
>> 
>> 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.
>
>  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.

Was JHDLBits reverse engineering the bitstream itself?

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

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

Jim Granville wrote:

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

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.

In article <QSVBf.14902$bF.4557@dukeread07>,
Ray Andraka  <ray@andraka.com> wrote:
>Jim Granville wrote:
>
>>  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
>> 
>> 
>> 
>
>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.

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