FPGA Journal Article
in [FPGA]
|
Prev: Xilinx Spartan3E Sample Pack 3rd party programing support now available
Next: porting linux on ml403
From: Antti Lukats on 19 Jan 2006 11:20 Martin Thompson" <martin.j.thompson(a)trw.com> schrieb im Newsbeitrag news:u8xtcb3o8.fsf(a)trw.com... > ptkwt(a)aracnet.com (Phil Tomson) writes: > >> 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? >> > > I believe so... maybe someone who runs Webpack (we have Foundation > here) can jump in? 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 :) -- Antti Lukats
From: fpga_toys on 19 Jan 2006 11:32 Antti Lukats wrote: > 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 :) > Antti Lukats 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?
From: fpga_toys on 19 Jan 2006 11:37 or for that matter even high speed consumer modems, as we would have remained stuck in the accustic coupler days.
From: fpga_toys on 19 Jan 2006 12:11 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?
From: Antti Lukats on 19 Jan 2006 12:26
<fpga_toys(a)yahoo.com> schrieb im Newsbeitrag news:1137688374.809626.35200(a)o13g2000cwo.googlegroups.com... > > Antti Lukats wrote: >> 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 :) >> Antti Lukats > > 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? > 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. Antti |