>> They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass produced to under cut them.

So how does having a closed tool chain achieve that? Aren't the FPGAs programmed either on the line, or from ROM at power up? Either way, board producers should be able to replicate the product. How does being closed help?

> So how does having a closed tool chain achieve that?

It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though yes, cruddy in various ways).

And to be honest, this conversation about the FPGA (and ASIC) toolchains being closed sources crops up again and again. They're closed source not because Altera/Xilinx/Microsemi need to keep secrets. They already know eachother's "secrets", and the FPGAs themselves are rather trivial devices. They're closed source not because users want them to be; again they couldn't care less. They're closed source because the userbase is absolutely tiny. A small userbase means we will only ever see tools that are sufficient. There is no benefit to Altera/Xilinx/Microsemi to put in extra time and effort open sourcing their work. And honestly, I wouldn't want them to. I'd rather their time and resources go into continuing to drive the price down and features up (as does every other company).

Not that I don't think opensource toolchains/devices wouldn't be great. I follow the MiGen/Milkymist mailing list where some open source FPGA tools are being developed. But in the commercial space, open sourcing FPGAs and their tools isn't the highest priority.

Going back to protecting designs, that's what bitstream encryption is for, which all modern FPGAs possess. Though Altera was quite late to the ballgame on that front with their Cyclone series...

   > I'm not sure what ChuckMcM was trying to argue.

If you create a circuit board which has all of the same chips as someone else, if you've changed the layout, you are completely within your rights to sell it as your own and keep all the money.

However, if you copy firmware, then creating a circuit board with the copied firmware is a copyright violation and you can be found guilty of copyright infringement at most of our trading partners.

For folks who built cloned CPU boards with a copyrighted BIOS they re-implemented the BIOS in a clean room to have their own "work alike" version, which then gave them the right to sell their boards.

If however you copy an FPGA bitstream, which is the compiled output of a copyrighted HDL description, you're in violation. But building a 'clean room' implementation of an FPGA bitstream is generally infeasible as it requires you to both know how the manufacturer encodes and encrypts it, and all of the functions of the internal chip.

A really great example of this in action was that the recent flap over "clone" FTDI USB to serial chips, wasn't a clone of the chip at all. Instead the cloners used an ARM M0 CPU with a USB peripheral and a UART peripheral and a bit of code that responded in all of the same ways in which the FTDI chip (which was presumably an ASIC) responded. That 'workalike' implementation was only possible because the set of inputs and outputs for that system are constrained, and the only IP violation was the re-use of FTDI's VID/PID pair. If they had been forced to use a bitstream file for an FPGA they would be liable for up to $30,000 per copy, and jail.

This feels like circular logic to me. We do not want the hardware companies spending time 'open sourcing' their docs because they need to spend that time and money 'making more features' which they wouldn't have to do alone if it was open, but we can't have it open because spending the time and money 'open sourcing' their docs......

I think there is a big difference between 'users wanting tools to be closed source' and 'users not caring if their tools are closed source'. And I would argue that even if the primary user base does not care, we can do better than that. It is no excuse to use these fragile lumbering behemoths of bad design and super seeeeecret tricks that you can learn in a university or the internet. And history keeps showing the problems of big black boxes with the words 'trust us' written on the outside. All we need is the layout and a map of the bitstream and open developers will do most of the work for these companies.

As for spending their resources 'driving prices down', that is quite relative. And if you look at the pricing model of their software it is clearly not their goal to make that reasonable (at least Xilinx). And every version of the software stretches to provide arbitrary bullet points on the back of a box that either mean nothing, were tested in suspicious conditions, or conflate multiple optimized tests together and say 'we are better than everyone at everything. How many times will that be said by all competitors at the same time, and how many times will it be believed? Anyways, with all those features, somehow ISE is still unstable on windows.

>>> which they wouldn't have to do alone if it was open

Well, that's an assumption. User base is very small, and potential contributors base is even smaller. So that would be a big bet hoping that someone would contribute to make it worthwhile.

However, your statement is true when it comes to more mainstream technologies like ruby or javascript.

But each company has it's own tools. That means redundant development. If they just worked on one set of open source tools, it should reduce development costs. It also opens the door to researchers to try things directly in the mainstream tools. That means not having to re-implement things published in papers, but instead deciding weather or not to merge a feature from a branch.

Sure the fpga companies don't want anybody to know how to build their software. Building good fpga's is not that hard(if you're intel, or quallcom or any other of the big guys). But building good, efficient software is very hard, takes decades and tens of thousands of customers designs to run it on.

When you say 'good, efficient software' i wonder if you are talking about Xilinx ISE/Vivado, or any of the tools from their competitors. I can not imagine you are.

Have you noticed anybody else with better software and chips ? no ? maybe because it's extremely hard to to get to the level of ISE and the competitors ?

'get to the level' of ISE... I disagree. I do not want to build an IDE. I want an open toolchain, the thing that the ISE interface calls. There is some math in there that takes certain skills to implement, but I know several people who could do it if they had the layout of the chips. MAYBE the reason there are no open toolchains 'on the level' of ISE and competitors is not because Xilinx has some amazing secret sauce and is instead because the whole industry is caustically secretive and horribly anti competition.

Well Quartus isn't bad. It will be interesting to see what Intel does with it. They have a history of open sourcing things other folks don't want to open source (like Graphics Drivers).

Some people have been preventing cloning by locking their bitstream to the FPGA's unique serial number, which exists partly to allow people to do this. This is trivial to work around if you know the bitstream and device internals.

I disagree that it is trivial. If we know what bits of the unencrypted bitstream do what, and have a cryptographically secure way of signing the stream, then GLHF with that. If it turns out that documenting the parts of the chip required for configuration makes the black box security not work, then it was crap security and provided no real security to anyone. As it stands there is no way to tell and we have to take the smiling sales guy's word that it is "SUPER secure, promise".

> Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them.

Could you provide further details?

http://www.xilinx.com/support/documentation/data_sheets/3000... is the data sheet. I used to have the programming and layout specs doc they gave out.

Are you sure it was the xc3000 that was documented and not the xc6200 series (e.g. xc6264)? I remember the xc3000 being documented the usual amount for their parts (pinout, architectural description, call for info about licensing the software you need to have to use the thing), but the xc6200 datasheet definitely included details about the bits and is still floating around: https://duckduckgo.com/?q=xc6200.pdf

Can you find the "programming and layout specs docs," online or physical copies? I can't find any mention of them anywhere. I'm very curious to see them.

But in how far didn't it do well for Xilinx?

Well the guy I know who used to be in charge of strategic marketing for Xilinx shared that it had not met sales projections and support costs were higher (which cut into margin) when people were trying to program the things with their own tools. So sharing all that stuff about the chip alienated some big customers, reduced profit margins, and didn't help volumes. That pretty much defines 'fail' in the chip business.

This is an interesting story. An unfortunate end. Most of these things sound like short term issues that get resolved as the tools are made. Alternately Xilinx could have just put the docs out there and said they only support ISE. That way if an open source developer makes a tool they have no responsibility, but can reconsider in a few years in case it gets wide acceptance. I am not a market strategist, but supporting everyone's custom tool sounds like a quick way to waste money and the wrong way to try and open source something. Similar to respecting every coupon people bring in, even hand written ones.

If there's so much value there, how are these companies stopping internal espionage? If a company wanted to see what their competitors were doing to gain a large advantage, they could certainly field a candidate to work as an agent for their competitor. It sounds like how Nikon doesn't document the NEF format and pretends their binaries are the only way to decode such files. Except obviously the secrets these hardware companies have is far more than a simple RAW format.

From what I've read of internal leaks, the leakers get caught and charged and dealt with, which discourages other leakers perhaps. But there isn't anything stopping an employee from selling or stealing company secrets. That hasn't changed.

But during the 70's and 80's a lot of manufacturers stopped printing schematics in response to clones appearing which used a circuit that was close (but not exactly like) theirs and sold at a deep discount[1].

Early computer board manufacturers used programmable logic to create special "nodes" within the system which obscured the functioning of things such that to clone them you would have to hire an engineer to understand the design and re-design it. Generally that was more effort than most of the cloner companies were willing to go through. (apparently if they had their own engineers that could understand the circuit they didn't need to clone, they could design their own)

FPGAs get you at least two layers of obfuscation, both the bit stream is encrypted and "decompiling" from the place and route configuration bits is not straight forward at all. Folks who have gone down the path of trying to figure this stuff out (as the OP is possibly doing) discover that changing a routing bit way in the front changes a bunch of other bits later but in very subtle ways. And routing in an FPGA is a great way of screwing up function, when you do timing analysis if you have to run at 200Mhz you have to make sure your setup and hold times are accurate to within a few nanoseconds across temperature and voltage differences. FPGA vendors tout this as a 'design security' feature some times.

Decoding this data is a lot more challenging than reverse engineering an image format.

[1] And yes you can argue this is just business, and it is, and this is just "business defense."

Thanks for all these great answers you've given - they're a nice compliment to the article, really explain a lot of why these sorts of decisions were made by the FPGA companies.