FPGA Journal Article

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

Reply to
Phil Tomson
Loading thread data ...

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@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
 Click to see the full signature
Reply to
Martin Thompson

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

Reply to
Andy Peters

one

So xdl come with the webpack?

Phil

Reply to
Phil Tomson

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

Reply to
Eric Smith

JBits,

Is a Xilinx invention, developed here.

Aust> Phil Toms>

Reply to
Austin Lesea

Do you happen to have a means to create a bitstream (from whatever ASCII represented primitives) on for example OpenBSD? Or from a perl script running on an OpenVMS system?

Your (the vendor's) tools so lovingly provided are not always the ideal tool for the job, nor is the environment always readily available in order to use them.

Yes, but how to convert XDL into something that I can shoot into the FPGA?

The gist is not really to compete in a space where a company has invested in millions to create a product, but to play in a space where nobody else is going.

But the tools are in the environment of your choosing.

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Reply to
Tobias Weingartner

Well, talking to actel, they cite "competitor" reasons for not giving away this information.

Xilinx (as much as this is "official" in any way) is citing a fear of being not able to meet the support issues.

Bullshit. I can get the bitstream and parts are readily available. There is little to no need to reverse-engineer your customers' design. It's right there for me to use, should I care to. Also, should I want to reverse-engineer things, it would not be *that* hard. I'm sure that I could get various pieces out of the bitstream that would be usefull to me (along with traces/etc) in doing a 80% job.

If you want security, provide it. Have a means to program a OTP flash (or somesuch) piece of hardware on your FPGA with an AES key, and have the bitstream flash device have its bitstream encrypted with the same key. At this point, things would considerably more "challenging" to reverse-engineer. I'm no VLSI designer, but I can't imagine that putting a simple AES engine onto the FPGA, along with some OTP ram for the key, would take any significant room. As a bonus, you may be able to offer the simple AES engine for the FPGA to use once programming is done.

Certainly. Does the "idea" I have given above (which is available in many forms on the web, etc) mean that you could use it, implement it, and have yet another innovative & profitable device on your hands? :)

Open documentation (not necessarily support) tends to foster collaboration and innovation on many fronts. The "encrypted config bitstream" idea is hardly new or novel, but I'm sure there are many people out there who would welcome the chance to get their creative juices flowing...

Darn. :)

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Reply to
Tobias Weingartner

I know what you feel like. We have the XC2S50 here on some demo boards from somewhere. They're ok to play around with. Nowadays I'm salivating over XC3S1500/2000 boards. If I could find something with 3 to 6 of these on board (even the 1000 version), and good chunk of sram, for less than $1k, I'd be a very happy camper...

--
 [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Reply to
Tobias Weingartner

Tobias,

-snip-

Not that we will not do what you suggest (someday), but reverse engineering OTP memory is very cheap, and is considered quite insecure.

That is the reason why RAM backed up by a battery is the only solution that is acceptable to the US federal government (FIPS-41), and to TV set cable box vendors...

The one time programmable key might be sufficient as a deterrent, and will certainly slow down the process of ripping off the design. I agree. But please do not put it forth as being "secure."

Austin

Reply to
Austin Lesea

Something like that; though I doubt the XC6200 would be the best starting point.

It looks possible, especially if the basic elements were a common-denominator subset of individual targets like Xilinx; e.g.

4-input LUTs followed by registers, with some sort of carry chain.

But no easier than behavioural VHDL code, in my opinion.

ummm, in a sense; if you are willing to use the "native" routing on each target, and allow each company's "native" tools to perform the routing, placement, bitstream generation (because they know the details of that target and its bitstream). And even then, you will lose some performance on at least some targets.

But that is a completely different issue than trying to keep every level of the design "open"...

IMO the closest you will get to allowing open tools to participate WITHOUT taking a big performance hit is the XDL approach. It's a text version of the NCD format - parseable and even human readable - with converters to/from NCD format. So you could potentially take an EDIF netlist and create open source tools to "map" it to an unplaced XDL, or use the Xilinx mapper and convert its output to XDL. Then create open source tools to floorplan, place and route in XDL format. Those portions of the tool flow are where the challenges are; and if you create something worthwhile, it would be useful to many Xilinx users.

You would realistically then have to use Xilinx tools to convert XDL to NCD and translate the completed design into a bitstream format. This is pretty much a straight translation and not very interesting in my book; though it would be a wart on an otherwise complete open source toolchain.

- Brian

Reply to
Brian Drummond

Tobias, we love universities and their students and faculty for their uninhibited free thinking, unburdened by mundane practicality. But beware that some of your sentences sound not just enthusiastic and uninhibited, but also ill informed. Life would be easy if the world were a simple as you see it. Of course we have evaluated non-volatile storage on an FPGA, and we offer a decryption engine in every Virtex-4 device that we ship. With battery-backed-up SRAM key storage, because we know that Flash storage offers no security worth talking about. And several smart people at Xilinx (and surely also in Altera) are still thinking very hard about a technically and economically viable solution. We gladly take advice. But it has to be more substantial than what you seem to offer. Peter Alfke

Reply to
Peter Alfke

the

True. The only gains might come when describing memories and other larger blocks which tend to be different from family to family... but there are other easier ways of 'genericisizing' those things too.

Is XDL described anywhere? Grammar or BNF? Or is it based on XML? (probably not likely, but one can wish)

Well, you have to start somewhere.

Phil

Reply to
Phil Tomson

I showed my homebrew club how to reball and attach Xilinx BG560's here in my wifes digital convection oven well over a year ago. It takes a small amount of practice, which gets manageable when you also are willing to bake and reball. There are lots of trash FPGA's to be had on boards for a few dollars, and Solderquik preforms make reballing easy.

KISS projects can frequently be pulled off with double sided boards, which are cheap from a number of sources. If doing BGA, they need to be solder mask over bare copper (SMOBC) to prevent the balls from wicking under the mask.

There should not be ANY expensive home project from a parts perspective, as recycling motherboards, industrial boards, disk drives, graphics cards, etc are a wealth of nearly zero cost parts. Design with what you can salvage, and that is a lot.

I strongly suggest forming a home brew club locally, or even across the net, and pooling designs onto a PCB panel ... especially when 4, 6, and

8 layer projects are needed. Most of the budget pcb shops refused panelled designs, but you can lower your individual costs by sharing NRE's and setup charges across 3-10 project boards on the same panel. Just be sure that you can cut them apart :)

I'm pretty sure there are a LOT more than just a few of us. I made PCB's in high school (1967) with masking tape for resist, and stoped making them at home when the pcb program showed up for my MacIntosh 128 from Douglas Electronics. I even stopped wirewrapping about that time because it was just quicker and easier to turn one PCB with data paths and most control paths in place, and finish the design with point to point wiring and PAL's.

My first BIG hobby project was a Z80 based 9-track tape formatter for the TMS100 tape drive I had on my LSI11/23 Unix home computer, which I had to go buy a TRS-80 to write the firmware for.

My current home computer project is a couple thousand FPGA home super computer, which I've been working toward for a couple years now, mostly because I like big fast computers, it's one hell of a challenge, and I needed retraining in building state of the art computer systems after being a Unix systems programmer for too many years.

I do knock off flat fee contract hardware and software designs from time to time, and I'm also currently looking for projects. I will also be turning some of the smaller spare fpga's from my home computer project into low cost student boards - using environmentally friendly recycled parts.

John

Reply to
fpga_toys

I should probably add that Steve's Icarus Verilog (IV) solves that problem in the low cost open source tools department. And it works well targeting fairly good sized XC4K's and Spartan chips which are easy to design with since they only require a 3.3V supply. Pick off an older Seagate drive, and you will have a dual 1a linear regulator, 2MB SDRAM, EEPROM with boot sector, cap's, and a few other parts to build an interesting robot controller, stomp box effects processor, home controller, or other project with a

5V recycled wall wart.

And FpgaC for open source reconfigurable computing (read executing C code as circuits) is getting off the ground to do the same for C coders not interested in learning VHDL/Verilog as their only way to program fpgas.

You will find both FpgaC and IV on sourceforge.

Reply to
fpga_toys

Actually, I would like to compile, load and go fair sized algorithms without having to spend hours in place and route. I would also like to dynamically link library elements on the fly without having to do a xilinx style design partition. But these are what software guys want using FPGA's as computers. I'm willing to constrain the compiler into bin sorting logic blocks into acceptable clock domains, and cross clock domain synchronize when the execution switches clock domains. I'm pretty sure that the compiler can generate logic blocks in RPM's that will have reasonable performance for testing, and would be just happy as a lark if I didn't have to wait for place and route till a project was completely done.

It comes down to the difference between hardware guys needing to optimize cycle times for production needs, and software guys just wanting something that will work for testing - two very different ends of the spectrum. I would be very happy with place and route tools that I could give a polygon constraint, and a few interconnect points to the existing design, and have it return and xor'able bit stream referenced to a null design for the polygon that i could load on demand. Oh, and it would be really cool, IE necessary, to do that in under a second or two, preferably milliseconds.

When there is an fpga vendor that can support partial reconfiguration on the fly with dynamic linking of modules with times in the microseconds or milliseconds then we will see reconfigurable computing go main stream big time. Right now it still feels like compiling my 1401 programs with an N-Pass card deck compiler to punched cards. The level of reconfigurability and the granularity of the tools is completely bent toward hardware design processes .... some of us would like a LOT more.

Reply to
fpga_toys

yep, and that is the problem. A really useful tool for reconfigurable computing and self hosted incremental compilers using fpga's as computers would have been JHDLbits, a project stalled because the university was (as I understand it) unable to get a release to take the project open source because of NDA with Xilinx.

A lot of the technology we could use for compile, load and go supported with dynamic linking for reconfigurable computing with FpgaC has been sitting NDA locked for over a year.

Aust> JBits,

Reply to
fpga_toys

That is easily handled by a solid policy of "unsupported" features, which can be selectively waved by the company for selected fully paying customers which have volume to merit a response.

Security by obscurity has never worked ... just look at the weekly exploits to microsoft windows that result largely due to reverse engineering.

Any engineering team in the world that can manufacture a cloned product without legal recourse will do exactly that, via reverse engineering if necessary, including die probing live parts if necessary. There just has to be an economic social, or political incentive first.

exotic academic, or hobby stage, engineering is where garage innovations create new industries.

Reply to
fpga_toys

via NCD (xdl -xdl2ndc) and bitgen

Ahh well, that is a bit of a limitation :-) They may run under dosemu... They will under Wine I seem to recall... You could port that to OpenVMS first :-)

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
 Click to see the full signature
Reply to
Martin Thompson

one

I believe so... maybe someone who runs Webpack (we have Foundation here) can jump in?

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
 Click to see the full signature
Reply to
Martin Thompson

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.