Forums

So what happened to JHDLBits?

Started by Phil Tomson January 25, 2006
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