for just the purpose of knowing what is in WebPack I have installed additionally so I can answer : yes the XDL is included with free WebPack
but the XDL (or NCD) does __not__ contain bitstream info, it does hold the design info that is not mapped to the bitstream by bitgen later
NCD (that can be viewed as XDL after conversion) is used together with BFD (NeoCad Bitstream Format Database ?) file by bitgen for actual bitstream generation.
there are some other files for each family, like GRD, etc I am able to view pretty much all of the files used by Xilinx tools, (NGC, NCD, etc) but... the path from NCD to bitstream is not so 1:1, I have written some analyzer software for the BFD to see if there is some visible mapping but the result have been a little confusing so far. oh well I dont have all the for such a play,
but the reversing of the bitstream info is for sure doable just need to write some smart analyzer and bit map database auto generation software and let it run for long time to gather the info for you :)
You might want to look a little closer at the license for the web pack, and any other license you have ever executed with Xilinx, as it wasn't that long ago that it contained very strong language about reverse engineering proprietary data.
With the current DMCA state, the law isn't hardly on the side of fair use for computer software or hardware owners these days. It's terribly like owning a car, but unable to remove the heads to repair a valve without getting sued.
Or when the telco's prevented third party phones from being attached to their systems. When finally lifted an entire industry blossomed bringing us cheap cordless phones and digital answering machines that would never have appeared with the PUC mandated 10 year capital recovery limitiation on hardware. Ever wonder why WeCo had to over design the clunky 500 desk set?
I probably should add that the whole process for assembling fpga bits streams is optimized poorly for reconfigurable computing - if not outright wrong and backward. In hardware design you break the design into one or more clock domains and fine tune the designs timing constraints in those clock domains.
For reconfigurable computing, as a comodity general purpose processor engine exactly the opposite process needs to occur. The Hardware WILL have fixed clock rates available, and maybe even a few setable ones, but in general the compiler needs to match code blocks to available clock periods, even if it's mismatched by as much as a factor of 2-5. With some basic worst case timing data for the target fpga's this is easily done, and the compiler can bin sort statement blocks into clock domains on the fly, and emit synchronizers when necessary to cross clock domains. This allows statement groups which have horrible combinatorial delays to run at one clock speed, and other statement groups with very flat netlists and little to no combinatorial delays to run at a faster clock rate ... "all the compiler needs" is some clues about general timing costs and the actual runtime target capabilities. In some cases this even can be done by fixups by the 'runtime linker" just prior to loading.
The practial clocking environment for this would be a series of edge synchronized clocks spread a factor of two, three, four or five in time (so rising edges always match) to avoid synchronizers completely. In such a target execution environment, the one hot state machine gating the execution flow can freely cross clock domains.
Some with a runtime life in days can surely have it's clocks fine tuned, but for most applications this granularity is quite reasonable.
Now, how practical its it to hand a netlist with 8 interleaved clock domains to your favorite vendors place and route tools, and get back verification of setup and hold times for this environment?
schrieb im Newsbeitrag news: snipped-for-privacy@o13g2000cwo.googlegroups.com...
well I am not doing anything, I just know what can or could be done :) [pretty much anything...]
Atmel bitstream info is all known and its fully runtime reconfigurable so it makes way more sense to go with Atmel FPGA/FPSLIC if someones wants self or dynamicall reconfiguring FPGA systems.
It's described in comments in the XDL file itself:
Here's some of them pasted out of one of mine: # ======================================================= # The syntax for the design statement is: # design ; # or # design ; # ======================================================= # The syntax for instances is: # instance , placed , cfg ; # or # instance , unplaced, cfg ; # # The syntax for nets is: # net , # outpin , # . # . # inpin , # . # . # pip , # [] # . # . # ; # etc..etc... More details then follow on some of the details.
So it is fairly straightforward to understand, assuming you understand the architecture it's talking about already...
I have made a start on a python parser for XDL which creates a pysqlite database as the backend. Conekt owns it, but they may be persuaded to open source it.. I wonder...
Cheers, Martin
--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt
Indeed. Any such block should have a completely generic entity, preferably with a generic architecture, which will at least work for simulation. If that synthesises down to a million FFs instead of a BRAM, you can always substitute architecture X or A as appropriate. With configurations, if the tools support them properly.
Sure, a ROM may be such. I dont really care how it's implemented, but if done as a "persistant write-only" area of the FPGA (from a user's point of view)... if that is battery backed ram, flash, whatever. I'll leave the finer details to the VLSI designers... :)
Umm, pretty much the same as the next step had someone given you the bitstream coding. XDL makes it nice because you can play with just one part of the implementation process and let the existing tools do the rest, rather than having to reinvent the entire implementation chain. What more could you want?
Sure, I understand that. I guess to rephrase my question and expand it: if we had a an XDL parser and the ability to generate and modify XDL programatically (and this ability is potentially even more interesting than being able to parse XDL, I would think) how would you go about using a set of tools like that?
I ask the question, because how the tool would be used (or how people would like to make use of the capability ) could help define the features the tool should have and how it should be developed. I'm looking for some early input in the design process.
Since bitstreams will likely always be proprietary and it's agreed that XDL manipulation is the next best thing (at least for Xilinx parts), what's most important in an XDL tool suite?
In looking at some XDL it just seems like a structural description of the design using a Xilinx 'library' (with placement info included). The format itself seems easy enough to parse, however the devil is in the details (knowing valid placements, routings, pins, finding equivilent mappings, etc.). While parsing might be easy, making changes or generating completely new XDL files and determining if they are correct could be very difficult - is the sort of info that's required even openly available (without NDA)?
Seems like there are lots of possibilities including open source simulation/synthesis/translation/p&r tools, etc. and long term that might be the way some might want to use the capability to read(parse) and generate XDL. However, any of those would be very ambitious projects (and one wonders if XDL is the right place for doing some of those things). Short term, what gives the best 'bang for the buck'?
...and here's a concern I have: If an open source ecosystem were to grow up around XDL might Xilinx decide that they are uncomfortable with that and at some point in the future pull the plug by not including the XDL utility in their tool suite anylonger. The point being that we will still have to rely on some closed source tools (xdl -> ncd -> bitstream) which could disappear at any time or be changed so that they no longer operate the way they do now. Is it a valid concern?
One option would be help with floorplanning or placement.
My ideas on this are ill-defined, but here are a couple of suggestions...
(1) (this might be easier at the EDIF stage rather than the XDL stage) for each register, identify the logic levels to the next register, and allocate a notional timing to each such level according to its type (e.g. high for LUT delays, low for carry chain). Sum those timings; the aim being to find the critical paths and attach a "tight" placement to them (or modify the existing placement if you think you have found an improvement)
Initial steps would be experiments to see (a) if we can reliably identify probable critical paths (i.e. those with most LUTs between registers (b) if we can modify placement in XDL and have the Xilinx tools successfully route the result, without looking for timing improvements. (c) identify hierarchy from signal names (hence my wondering about EDIF) and generate placement in a "floorplanner" like manner by regular placement of buses, registers etc. (d) then go on to try and beat the Xilinx tools. At which point we might find their "cloud of LUTs" placement is highly optimised already...
(2) take a post-PAR design which fails timings and a possibly hand generated (*) list of "problem" components and try to improve placement for those specific locations. Again, let Xilinx router take over...
(*) related project: parse a .TWR or delay report to generate such a list.
One important thing is to supply missing functionality.
It always bugs me there is no way back into the placer, once the router has discovered what the placement problems are! Using "MPPR" is a brute force way of "fiddling" with the placement, discarding the router's hard-won experience instead of recycling it. The fact that an MPPR set can show 10% or so variation in fmax on the same design suggests there is something to be won here.
A tool which took a failed PAR and its TWR and had, say, 80% chance of fixing the failing paths quite quickly (i.e. not overnight!) might win a few friends...
It ( = no.2 above) looks achievable (maybe with sub-100% success rate). Hand-waving evidence: I have maybe 30% or 50% of the time, moved a couple of obviously badly placed elements in FPGA editor and met timing. Other times I have fixed the error I was working on but created 50 more. But I can only search slower than FPGA editor can draw; a machine could search many more options and search deeper, looking for disastrous consequences of a simple looking move. (e.g. if the offending LUT is halfway up a carry chain, watch out!)
For bonus points, let it replicate that FF (or LUT in a carry chain) that REALLY needs to be in two opposite corners of the chip at once!
A first pass would probably have to be restricted to single clock domain designs, or otherwise simplified, as a proof of concept. Also, it would suffice to rip out the routing where you move something, and let PAR take over on the result.
If XDL helps sell Brand X chips ...
Another valid concern would be - if the open source tools actually DID embarrass the in-house ones (say, achieve 10% better fmax 50% of the time), what do Xilinx do? I don't see them discouraging performance improvements ... I do see them wanting to incorporate the best ideas into their own tools. But how?
And if they don't embarrass the in-house tools, where's the problem?
But again, how would we get back into PAR from XDL, can you offer more details? I suppose if PAR doesn't accept XDL, that it must accept a list of critical nets and we would generate that based on the knowledge extracted from the XDL and timing report.
Offer us jobs (telecommuting jobs where we don't have to move to the Bay Area, please ;-)? Maybe just a cash reward would suffice ;-)
I suppose you're right. It's just that in my experience corporations like control (that's mainly why bitstreams are closed, right?).... what was it I read recently (I think it was in Businessweek) something about how most corporate organizations look a lot like the Soviet Politburo and that while democracy has made huge inroads all over the world, it hasn't made much progress in corporate America. Seemed apt.
"Phil Tomson" schrieb im Newsbeitrag news: snipped-for-privacy@enews2.newsguy.com...
XDL is almost the same as NCD and as NMC (hard macro) is actually also a NCD I think it is possible to create XDL based hard macros that are converted to NCD and renamed to NMC then used again by PAR that could be one way
No, but it can translate back to a new .ncd file. Which WILL go back into PAR - look at "re-entrant routing" and/or "guided design" in the documentation.
I don't think you need more than the above - and I haven't tried it since Foundation 3.1. It seemed to work but I don't recall actually modifying the XDL.
The more I think about it, the more this one appeals. It's simple, pragmatic, and fairly testable.
Well, who knows? ;-) Look at the record so far ... what happened to Neocad, whoever wrote PlanAhead, and now AccelChip. Even the late lamented XC6200 originally came from a Scottish startup,
formatting link
and I honestly believe Xilinx tried to make it fly for a few years.
Well, IMO we can give them that control by not fighting them on Bitgen (the uninteresting "translation") AND get most of what we want (openness on the interesting bits, i.e. where you can win/lose performance) using XDL.
Should probably start a development wiki somewhere so we can document some of these ideas better. That'll have to wait 2 or 3 weeks until after my current projects are finished...
Well, those were companies.... I'd prefer to stay on the open source side for most of this, but maybe there's a way to do a startup that's totally open source (?)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.