Low level FPGA programming

[xyz]

It is clear, that with Xilinx software and VHDL ane can programming FPGA.

 

My question is: Where I can find protocole to programming logic cells directly? For example if you have none standard os, then how you can programming Spartan 6 FPGA?

 

[johnbeetem]

If you're talking about downloading a bit stream to a Spartan-6, you should be able to do that from any computer.  See Xilinx user guide UG380 Spartan-6 FPGA Configuration User Guide.

 

If you want to access the actual logic and routing cells yourself, Xilinx has never provided that capability.  Xilinx and all other FPGA vendors I know of (except for an Atmel FPGA that never caught on) do not document their bitstreams so that you can program them yourself, which means you are forced to use vendor tools.

 

If someone has information to the contrary, please post it!

[offroad]

Hi,

 

you can instantiate primitives, for example LUTs and RAMs. That's almost as good. The FPGA editor lets you do that sort of "hacking".

 

Directly manipulating the routing matrix seems like a recipe for a very expensive short circult circuit. They don't let you do that, and I wouldn't try.

[xyz]

Thank you johnbeetem.

I decide to find more, about configuration bitstream. In this paper:

http://drop.isi.edu/sites/default/files/users/nsteiner/soni-2013-bitstream-fccm13.pdf

it is written:

FPGA manufacturers are careful to protect bitstream details because ... and because the manufacturers would suffer severe financial loss if some-one were to produce bitstream-equivalent devices at lower cost.

Is this mean, that cell structure of FPGA is also not open (i.e. what components are contained in 1 cell)? Actually cell structure is essential for performance of FPGA.

EDIT:

In this place:

http://www.eejournal.com/archives/articles/20070227_drives/?printView=true

it is written opposit to above, i. e. that:

Many automotive qualified SRAM-based FPGA devices have an open configuration bitstream between the boot device and the FPGA that allows interception or downloading of the internal FPGA logic by unauthorized users.

[hamster]

The bitstream file is sent from the E

 

In this place:
http://www.eejournal.com/archives/articles/20070227_drives/?printView=true
it is written opposit to above, i. e. that:

 

What it is trying to say is that in most cases the bitstream file is not transferred over an encrypted link when the FPGA is configured, so it s quite possible to snif the data bus (or remove the EEPROM) and read it back. You could then clone the hardware and use that snffed bitstream to program it, giving you a complete clone of the device without actually knowing what the logic inside the FPGA is doing. 

 

A limited bit of reverse engineering is possible. For example, you could however extract the contents of the BRAM bits, and use that 'tweek' lookup tables or soft-CPU firmware, but you can't change the actual digital logic.

 

Having end-to-end encryption on the bitstream is considered a feature for protecting your IP against cloning by "those evil ones in that country" - the country that actually make the PCBs and hardware for you. 

 

It is often pushed as a "feature of difference" between FPGA vendors.

[xyz]

You explain this correctly. But in quote it is wrong to say "open configuration bitstream".

[offroad]

No, the quote is correct.

You can intercept the bitstream and put it to an identical device, and it will work (if the owner of the bitstream did nothing to prevent this).

The bitstream format itself is still mostly proprietary.

[alvieboy]

AFAIK, the bitstream, if not encrypted, can be mapped to each of the configuration bits on the SRAM. There's no published mapping however, but I think it has already been "reverse engineered".

If you have spare time, you can eventually use the FPGA editor to change some parameters, and then regenerate the bitfile.

Anyway, I don't think of a reason one would worry about how the bitstream is generated. The bit generation tool is free to use.

[johnbeetem]

Open FPGA architectures -- i.e., open bitstreams -- is something I've wanted for decades, so I try to advocate for open FPGA documentation whenever I have an opportunity.  I thank xyz for providing the link to Open-Source Bitstream Generation.  I'll have to look at its details when I have time to see how useful it might be in general.

The paper says: "FPGA manufacturers are careful to protect bitstream details because their customers are concerned about the possibility of designs being extracted and reverse-engineered, and because the manufacturers would suffer severe financial loss if some-one were to produce bitstream-equivalent devices at lower cost."

 

I think it's mostly the first reason (protecting customer netlists) rather than the second (afraid of competitive bitstream-equivalent devices).  In the latter case, the competitor would have to create from scratch software that has the same function to the established FPGA vendor, because using the established software directly would be a copyright infringement.  Similarly, copying every feature of an established device would most likely infringe patents still in force.  The basic Xilinx and Altera patents have expired by now, but they're constantly adding new architectural and circuit features which I'm sure are being patented as they're created.

So it's really hard to make a clone of an established chip -- it's like making a perfect copy of a modern ARM chip without copyright and patent violations.  It's easier to create a new architecture, or in the case of ARM, generally cheaper just to license it.

The closed FPGA excuse I've always heard is the first reason, that customers are afraid competitors will extract a netlist from a chip and then produce a cloned, cheaper product that won't be easy to detect as a clone because it has a different bit image.

Personally, I think this is a bogus argument.  The exact same argument can be applied to any CPU-based product, that someone could grab the binary software and make a clone.  Yet, people use open CPU architectures all the time and you rarely hear of products being cloned and/or reverse-engineered, at least in high-margin markets like North America and Europe.  The fact is that if you're copying your competitor's current products you're guaranteed to be one generation behind, and unless you make a direct clone -- obviously a copyright and/or patent infringement -- it's going to be just as difficult to reverse-engineer your competitor's product as to make an original product with better features.

Now, what's the historical impact of open CPUs versus closed FPGAs?  That's pretty obvious: microprocessor-based products continue to soar while FPGA usage is actually dropping.  See this recent Geek Times survey.

IMO, if FPGA vendors had opened their architectures to allow other people to write FPGA tools, FPGAs would have had as fast growth as microprocessors instead of always being second-tier technology.  IMO FPGAs have missed out on great opportunities like high-performance reconfigurable computing because of their closed architectures.  For example, here's a Geek Times article from 2007: FPGA Tool Bottleneck Stalls HPC.

FPGA vendors could change their practices at any time and recognize -- like ARM -- that open technology and a large ecosystem is the the path to success.  But if you've done business a certain way for a long time, it's scary to try something different.  Max Maxfield has an amusing Geek Times piece called Why Do You Do It That Way?  in which he talks about The Hermit in Robert Sheckley's Mindstorm.  The Hermit always speaks in verse when outside his hut, but speaks prose inside.  Why?  "I do not speak a prose language outside because I have seen too many men killed while speaking it; but I have not seen one single verse-speaker killed."

Yep, that sort of reasoning sounds familiar.

JMO/YMMV

[johnbeetem]

AFAIK, the bitstream, if not encrypted, can be mapped to each of the configuration bits on the SRAM. There's no published mapping however, but I think it has already been "reverse engineered".

If you have spare time, you can eventually use the FPGA editor to change some parameters, and then regenerate the bitfile.

Anyway, I don't think of a reason one would worry about how the bitstream is generated. The bit generation tool is free to use.

 

Bitstreams for various families have probably been reverse-engineered, but I don't think there's anywhere that complete results have been published.  FPGA vendors are quite sensitive about this.

 

Here's a reason that the free-as-in-beer bitgen is not adequate: you can only run it on x86 processors.  As the Open-Source BItstream Generation article points out, you can't run it in an embedded processor because it's "an x86 executable with significant data and OS dependencies".

[offroad]

IMHO, there is little point in getting bogged down at the bit level. I'd rather write inferable code, so I can take my design to another vendor if I want to.

No, the real challenge is (again, IMHO) that writing RTL is so very difficult, compared to simply coding it in C. There are a few applications where FPGAs shine, but those require a level of sophistication that is far beyond non-professionals (=folks who don't get paid for their time).

FPGAs are proprietary products in any case. I don't really see where non-proprietary tools would change anything.

[johnbeetem]

Hi offroad,

 

IMO writing RTL is not at all difficult in principle.  You just need to think differently about when your variables update.  The expressions are just Boolean logic, the same as you would have in a C "if" or "while" statement.  I suppose people who cannot stand C's conditional expression "a? b: c" might have difficulties with multiplexers, but you can't please everyone.

 

IMO the problem is not RTL in principle, but its chief languages: VHDL and Verilog.  The two languages are (shall we say) sub-optimal, and the hard part is learning how to write your source code so that the synthesizer produces the hardware you really want.  But guess what: as long as FPGA vendors control what tools you can use they also control what languages you can use.  Opening the bitstreams so alternative languages can be developed would go a long way towards making it easier to use FPGAs.

 

FPGAs are no more proprietary than a particular CPU family like x86 or ARM.  The difference is that the CPUs publish the instruction sets so that alternate tools like GCC can happen and we're not all stuck programming Intel CPUs in PL/M.

 

JMO/YMMV

[hamster]

I don't think that the HDLs are sub-optimal. The languages are flexible enough that anything that can be done with the hardware can be expressed in either of the HDL languages, That can't be said for general purpose programming languages like C...

 

However I don't think that HDLs shouldn't be thought of as a high level languages, more like a very very fancy assembly language for designing hardware devices. I think they sit below assembly language, but above the silicon level.

[offroad]

>> like a very very fancy assembly language

yes, and a fully concurrent one. I mean, writing efficient HDL is difficult, creating a design that is competitive against a CPU of similar cost or power.

 

>> Opening the bitstreams so alternative languages can be developed would go a long way

Why's that? Meta-programming is quite common, at least in academic circles. Generate Verilog / VHDL netlists and run them through the proprietary tool. Low-level access doesn't really help, IMO. I can always instantiate primitives if the synthesis tool "doesn't' get it".

Meta-programming generally works exceptionally well up to the point where you try to solve a problem that wasn't designed by the same guy who invented the specific meta programming paradigm I'v'e been dabbling with that myself for a while, leaving me with a good background in mixed-integer linear programming and the somewhat depressing insight that if it did work, all the RTL engineers would be looking for new jobs by now. They don't', and that tells a lot...

[johnbeetem]

I don't think that the HDLs are sub-optimal. The languages are flexible enough that anything that can be done with the hardware can be expressed in either of the HDL languages, That can't be said for general purpose programming languages like C...

 

However I don't think that HDLs shouldn't be thought of as a high level languages, more like a very very fancy assembly language for designing hardware devices. I think they sit below assembly language, but above the silicon level.

 

Like many people, I think of C as a portable assembly language that uses high-level notations.  Most C compilers provide an extension for inserting assembly language, which allows you to do whatever the hardware can do.  This is analogous to HDLs that allow you to include chip-specific components.  In both cases you lose portability.

 

The transformation from C to assembly language is usually pretty simple and you can easily predict what sort of assembly language will be produced for a sequence of C statements.  This is not true of Verilog, which is the HDL I use most of the time.  In order to get the Xilinx synthesizer to produce the hardware I want, I need to write the Verilog following a specific template and if I don't follow it exactly I can easily end up with far more logic cells than expected.  With a C compiler, I can take a look at the asm generated by the compiler and see where I made my mistake.  With ISE Webpack, the only way to see what code I generated is to look at automatically-generated schematics (generally useless for more than a single sheet of logic), use the FPGA editor (even more useless for large amounts of logic) or else try to decode XDL.  If I'm designing CPLDs the Xilinx fitter shows me what equations were generated, but I haven't seen an equivalent capability for FPGAs.

[johnbeetem]

Meta-programming generally works exceptionally well up to the point where you try to solve a problem that wasn't designed by the same guy who invented the specific meta programming paradigm

 

"I never meta-programming I liked"

 

I've never used meta-programming for FPGAs.  My impression is that it works very well for a well-defined, limited problem domain like DSP, but isn't useful if you're not in the tool's domain.  Your comment confirms that impression, so thank you.

 

Another issue with meta-programming is that now there's an additional tool layer.  I want my FPGA design loop to be as fast as possible -- adding another tool into the loop slows down the design process.  Plus, there's another level of uncertainty as to what hardware is being generated, which makes it that much harder to develop an efficient implementation.

 

JMO/YMMV

[offroad]

Another issue with meta-programming is that now there's an additional tool layer.

Yes, and the debugging starts to be real fun... With C we get a small taste of it (i.e. buffer overflow), in parallel RTL this gets much more difficult.

Unfortunately, that takes the fun out of alternative languages, at least for me. Verilog is a PITA but it just happens to work (so does VHDL but for me it tends to hide the forest behind the trees, structured data is nice to have though.).