From: Phil Tomson on
In article <dqg7ai$a67$01$1(a)news.t-online.com>,
Antti Lukats <antti(a)openchip.org> wrote:
>Brian Drummond" <brian_drummond(a)btconnect.com> schrieb im Newsbeitrag
>news:9p7ns1pch437c81ln9dunkk34bo5p2k3ab(a)4ax.com...
>> On 15 Jan 2006 21:39:16 GMT, ptkwt(a)aracnet.com (Phil Tomson) wrote:
>>
>>>In article <slrndsgqr4.i5.weingart(a)irricana.cs.ualberta.ca>,
>>>Tobias Weingartner <weingart(a)cs.ualberta.ca> wrote:
>>>>Kevin Morris wrote:
>>>>>
>>>>> Any takers?
>>>>
>>>>Real/Complete programming information would be a very good start to a new
>>>>hobby phase. But I think that all the FPGA vendors are too scared to
>>>>give
>>>>out this information. Come on, xilinx, altera, etc, etc. What could
>>>>there
>>>>possibly be so secret in the format for how to program your parts? :)
>>>>
>>>
>>>Indeed. I don't get it either. How much can be reverse engineered from a
>>>bitstream format? This closedness is a real hindrance to the development
>>>of
>>>an open source eco-system around FPGAs.
>>
>> Last really open system was the XC6200. But it failed commercially, at
>> least in part, because it was a finer grained architecture.
>>
>> FPGA capacities should now be big enough to support a "virtual FPGA"
>> layer on top of a real FPGA, using only the "public" parts of the
>> bitstream (e.g BRAM and SRL16 contents, possibly a subset of the
>> routing) to give a completely open format. Possibly a virtual XC6200,
>> but probably a coarser grained architecture (mini-Spartan perhaps).
>> I wonder what size Spartan-3 you would need for a virtual XC6264?
>>
>> This would lose a lot of capacity and performance (you may need several
>> LUTs dedicated to routing for every one you can use for logic) but the
>> result is likely to be at least competitive with the sort of technology
>> a startup or small player has on offer.
>>
>> I think it would be big enough to exercise open source development tools
>> until something better came along...
>>
>> - Brian
>>
>>
>
>it has already been done there was MPGA project that implemented a virtual
>"Meta" FPGA
>the project is dead vanished/vanishing but its a nice a example of the use
>of SRL16 for
>virtual FPGA loading
>
>its however far more interessant to implement dynamic bitstream generator
>that patches
>some parts of the ready made bitstream to modify the algorithm this needs to
>no
>resources to be vasted for the download of the new config.

But this would require that we know the bitstream format, right? Can you
elaborate a bit (no pun intended) on this dynamic bistream generator idea?


Phil
From: Martin Thompson on
ptkwt(a)aracnet.com (Phil Tomson) writes:

>
> Where can one find more info on NCD and XDL file formats (and what the
> acronymns stand for)? Are you implying that if one has this NCD file that one
> can figure out the bitstream format?
>
> Phil


As I understand it, the XDL is a textual representation of NCD. The
NCD is the native circuit database, which has pretty much everything
required to make a bitstream (logic, placement, routing, startup
values, BRAM contents etc). If you run "xdl -ncd2xdl" you can get the
XDL equivalent, hack it about and then regenerate the NCD from the XDL
and from there go to a bitstream... You can also get a list of all
the resources in the device using the -report mode of "xdl".

Presumably you could create various small designs in XDL, NCD them and
then convert to bitstreams and by diffing the bitstream figure out
what was going on. In theory you could also automoate this...

Cheers,
Martin

--
martin.j.thompson(a)trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

From: Andy Peters on
Phil Tomson wrote:

> Where can one find more info on NCD and XDL file formats (and what the
> acronymns stand for)? Are you implying that if one has this NCD file that one
> can figure out the bitstream format?

If I recall correctly, the NCD format came from Neocad, a company whose
P&R tools were better than Xilinx' own. So Xilinx bought 'em. This
was back when the XC3000s were the bleeding edge.

-a

From: Phil Tomson on
In article <uzmltkjm9.fsf(a)trw.com>,
Martin Thompson <martin.j.thompson(a)trw.com> wrote:
>ptkwt(a)aracnet.com (Phil Tomson) writes:
>
>>
>> Where can one find more info on NCD and XDL file formats (and what the
>> acronymns stand for)? Are you implying that if one has this NCD file that one
>> can figure out the bitstream format?
>>
>> Phil
>
>
>As I understand it, the XDL is a textual representation of NCD. The
>NCD is the native circuit database, which has pretty much everything
>required to make a bitstream (logic, placement, routing, startup
>values, BRAM contents etc). If you run "xdl -ncd2xdl" you can get the
>XDL equivalent, hack it about and then regenerate the NCD from the XDL
>and from there go to a bitstream... You can also get a list of all
>the resources in the device using the -report mode of "xdl".
>
>Presumably you could create various small designs in XDL, NCD them and
>then convert to bitstreams and by diffing the bitstream figure out
>what was going on. In theory you could also automoate this...
>

So xdl come with the webpack?

Phil
From: Eric Smith on
Phil Tomson wrote:
> It looks like JBits is a University-developed tool. why wouldn't the source
> code be available?

If it really was developed at a university, the university probably signed
an NDA with Xilinx to get the bitstream details.