Life after XDL

[Neil Steiner]

If you know and love XDL or XDLRC, and if you believe that the research community's access to these tools provides a benefit to Xilinx, this is your opportunity to speak up.  The xdl tool will no longer be available as of ISE 14, and unofficial word is that Xilinx does not intend to provide equivalent capability.  We don't believe they're deliberately trying to withhold that capability:  We simply think they see it as a distraction that provides no benefit for them.

For those who may be unfamiliar with these tools, XDL is a format that can be converted to or from mapped NCD, allowing the user to modify any part of their circuit or its placement or routing, or to perform arbitrary placement and routing of their own.  XDLRC provides all of the logic and interconnect data for real Xilinx devices, and enables research into CAD algorithms for real devices.

A colleague from BYU (representing RapidSmith) and I (representing Torc) are scheduled to meet with the Xilinx software folks in two weeks to discuss this matter, and to appeal for continued functionality equivalent to XDL and XDLRC.  We have no wish to barrage or pressure them in any way.  The data is theirs to do with as they think best.  But to the extent that our community's access to XDL benefits them, we would like to present that case to them.

I am collecting and framing our arguments, and am open to any contributions from the comp.arch.fpga community.  Any of the following would be helpful to our cause, in rough decreasing order of importance.  And I relax the strict meaning of XDL here to include capabilities and low-level device knowledge enabled by XDL:

• Evidence that XDL is used by Xilinx paying customers.
• Evidence that XDL is used by real companies or in real products (or anything in orbit or beyond).
• Evidence that XDL enables truly novel research and helps differentiate Xilinx from competitors.
• Evidence that XDL has encouraged universities to adopt Xilinx tools in classes.
  
• Evidence that work from the research community based on access to Xilinx data has benefited research or development at Xilinx.
  
• Evidence that XDL has helped researchers win funding.
• Evidence that access to Xilinx data has resulted in a good pool of candidates for Xilinx to hire from.
  

We do not believe the community's mere desire for access to XDL and XDLRC carries any weight with Xilinx.  But Xilinx is a commercial company, and anything that aligns with their business model or objectives, or increases their sales and market share, is likely to catch their attention.

XDL and related capabilities have been central to my research for the past ten years, so I am well aware of what we stand to lose.  There are some sympathetic voices within Xilinx, but we probably should not ask them to make the case for us:  We need to do so ourselves.  If you have good suggestions, feel free to respond here, but please also copy me at mailto:neil.s...@isi.edu?subject=comp.arch.fpga%20XDL%20suggestions.

Regards,

[Martin Thompson]

I too have tools which make use of XDL (one of which some of you may
have used - FPGA Optim); so after Neil's heads-up, I contacted my local
Xilinx guy and got this response (which I must make clear is not an
"official factory response"):

"Because of the database change in Rodin, XDL is not part of this new
tool. This is being debated by the technical teams at Xilinx. One
solution offered so far is to use TCL instead as this will enable full
access to the database to change the FPGA design / routing similar to
XDL."

So, there is an awareness of the problem, and hopefully a (albeit
different) solution, although it sounds like they are not committed to
providing it at the moment.

Cheers,
Martin

--
martin.j...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

[Jan Bruns]

Neil Steiner:

> If you know and love XDL or XDLRC, and if you believe that the research
> community's access to these tools provides a benefit to Xilinx, this is
> your opportunity to speak up. The xdl tool will no longer be available
> as of ISE 14, and unofficial word is that Xilinx does not intend to
> provide equivalent capability. We don't believe they're deliberately
> trying to withhold that capability: We simply think they see it as a
> distraction that provides no benefit for them.
>

> /For those who may be unfamiliar with these tools, XDL is a format that

> can be converted to or from mapped NCD, allowing the user to modify any
> part of their circuit or its placement or routing, or to perform
> arbitrary placement and routing of their own. XDLRC provides all of the
> logic and interconnect data for real Xilinx devices, and enables

> research into CAD algorithms for real devices. /

> A colleague from BYU (representing RapidSmith) and I (representing Torc)
> are scheduled to meet with the Xilinx software folks in two weeks to
> discuss this matter, and to appeal for continued functionality
> equivalent to XDL and XDLRC. We have no wish to barrage or pressure
> them in any way. The data is theirs to do with as they think best. But
> to the extent that our community's access to XDL benefits them, we would
> like to present that case to them.
>
> I am collecting and framing our arguments, and am open to any
> contributions from the comp.arch.fpga community. Any of the following
> would be helpful to our cause, in rough decreasing order of importance.
> And I relax the strict meaning of XDL here to include capabilities and
> low-level device knowledge enabled by XDL:

I'm only a hobbyist, so I actually don't have any evidence about
financial matters.

But I've noticed the existance of the XDL tool, and used it a few times,
but just for informational purposes. Using fpga_editor, I've noticed that
the automatic router is sometimes pretty difficut to guide. It sometimes
gives up searching for completely obvious, essential solutions.
Timing costraints can help in finding out if an essential solution was
found, but don't give the router all the already known information
about modules. For example,. things like "just priotize these signals and
everything will easily work out as the timing constraints told" just imply
theoretical satisfyability, but no real world solution, if there's no way
to tell the tool.

"No way to tell the tool" + "stupid hobbyist realized it" prooves that
there should be third party tools "to tell the tool" in some of the
commericially more relevant workflows.

Gruss

Jan Bruns

--
Ein paar Fotos: http://abnuto.de/gal/