Life after XDL

N

Neil Steiner

Guest
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.steiner@isi.edu?subject=comp.arch.fpga%20XDL%20suggestions.

Regards,
 
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.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
 
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/
 

Welcome to EDABoard.com

Sponsor

Back
Top