Role for FPGA or CPLD with Raspberry Pi

On DesignSpark:

• TAUTIC - CPLD Development Board Review
• http://www.designspark.com/content/tautic-cpld-development-board-review

The red board connected to the black CPLD header is the Bus Pirate he mentions.  I've got one of those, and they're very handy little gadgets.

At that CPLD size, I'd just go with a Xilinx XC9572XL-10TQ100CXC9572XL-10TQ100C in a 44-pin PLCC, which plugs into a PLCC socket, which in turn plugs into a wire-wrap socket or socket strips.  For some reason, I've often found 72 macro-cells to be just enough and 64 macro-cells to be "not quite enough".  XC9500XL are even older than Coolrunner-II, but they're still listed on the top CPLD page at Xilinx.com.

Edit: it seems someone changed my reference to the 9572XL into a full part number including -10TQ100C.  I don't mind, except that the TQ100C is the 100-pin TQFP package.  If you want to wire-wap, you'll need the 44-pin PLCC version which is XC9572XL-10PCG44C.

Roger Wolff wrote:

 

read: http://lekernel.net/fpga_toolchain_talk.pdf

Some attempts have been made. I found several links to ulogic.com which was said to have reverse engineered a xilinx bitstream. Site has vanished.

I believe the ulogic.com site had an implementation of the work described in this paper: From the bitstream to the netlist.  Here's the key quote:

It is widely believed that the analysis of bitstream formats is a daunting task.  In fact, it is surprisingly easy.  This paper presents a methodological approach to bitstream reversing illustrated with a case study on the Virtex FPGA lines from Xilinx.

John Beetem wrote:

 

I believe the ulogic.com site had an implementation of the work described in this paper: From the bitstream to the netlist.  Here's the key quote:

It is widely believed that the analysis of bitstream formats is a daunting task.  In fact, it is surprisingly easy.  This paper presents a methodological approach to bitstream reversing illustrated with a case study on the Virtex FPGA lines from Xilinx.

Unfortunately it's a bit of a foregone conclusion that if a useful tool were ever produced after reverse-engineering the format and it gains popularity, Xilinx would respond by making their next bitstream encrypted.  And while the hardcore hackers may see that as a fun challenge, for those interested in open source engineering rather than chasing tail lights, it's a poor road to take.

John Beetem wrote:

 

1.  The last time I looked, it was pretty simple to find the registers that program the "12C4" PLDs in a Cypress PSoC5, which is an ARM Cortex-M3 with an attached array of digital and analogue goodness.  (There's also an 8051-based PSoC3.)  So even if you can't figure out a way to re-program the digital interconnect, you could have a fixed routing of one or more "12C4" PLDs to the I/O pins and use the ARM to talk to a RasPi for reconfiguration and internal signal probing.  This gives you one or more PLDs, with the programmer is on the same chip.

There could be quite a lot of milage in that approach, particularly in the light of recent developments.  I read on this page on Dangerous Prototypes' site --- freesoc-psoc-dev-board/ --- that very recently a successful Kickstarter project is aiming to produce a couple of cheap open hardware boards for PSoC5 --- http://www.kickstarter.com/projects/18182218/freesoc-and-freesoc-mini

Morgaine Dinova wrote:

 

Unfortunately it's a bit of a foregone conclusion that if a useful tool were ever produced after reverse-engineering the format and it gains popularity, Xilinx would respond by making their next bitstream encrypted.  And while the hardcore hackers may see that as a fun challenge, for those interested in open source engineering rather than chasing tail lights, it's a poor road to take.

Xilinx offers optionally-encrypted bitstreams in all of their latest FPGAs and some of their older high-end Virtex parts.  Since encryption is now available on all recent parts there's really no reason for Xilinx to keep the bitstream format secret.  This is particularly true of parts with built-in CPUs, since the CPU can program the FPGA from a bitstream encrypted any way the CPU's software desires, without exposing the bitstream to any external pins.

Morgaine Dinova wrote:

 

John Beetem wrote:

 

1.  The last time I looked, it was pretty simple to find the registers that program the "12C4" PLDs in a Cypress PSoC5, which is an ARM Cortex-M3 with an attached array of digital and analogue goodness.  (There's also an 8051-based PSoC3.)  So even if you can't figure out a way to re-program the digital interconnect, you could have a fixed routing of one or more "12C4" PLDs to the I/O pins and use the ARM to talk to a RasPi for reconfiguration and internal signal probing.  This gives you one or more PLDs, with the programmer is on the same chip.

 

There could be quite a lot of milage in that approach, particularly in the light of recent developments.  I read on this page on Dangerous Prototypes' site --- freesoc-psoc-dev-board/ --- that very recently a successful Kickstarter project is aiming to produce a couple of cheap open hardware boards for PSoC5 --- http://www.kickstarter.com/projects/18182218/freesoc-and-freesoc-mini

Thank you for the pointer.  According to the comments:

Zeta says:

 

after all, if you want to configure the PSOC without any IDE or just a XML file you can do it by issuing standard JTAG commands from any Unix-ish machine. All the registers are well documented in the reference material.

The last time I looked, some of the registers were well-documented but others not.  I haven't looked at the Register TRM in a while, so maybe I should... or else wait until I have some tools and then look!

OK, I took a look.  Here's the complete description of one of the Digital System Interconnect registers:

hc_byte[7:0]   RAM configuration for DSI channel bytes

Yeah, that's really helpful.  I guess I'll have to wait for Register TRM rev C... or D... or E...

Oh, if anyone has a link to the information I need to program the DSI, please feel free to call me an ignoromnibus and show me where to find it.  I'd really like to be proved wrong on this.

John Beetem wrote:

  However, I've heard over the decades that the bit format is not that hard to reverse-engineer.  The problem is that if you publish the results you could be sued.

Reverse engineering for the purpose of making a compatible product (as opposed to competing!) is already legal in Europe. This overrules whatever EULA you signed or clicked when starting to use the product.

Of course they prohibit reverse engineering  in the EULA, and then hope you don't know the law.

If you're making a word processor that needs to read microsoft word files, the situation is a bit vague. You're replacing "microsoft word". But in the case of the FPGAs we're discussing we are NOT interested in selling FPGAs ourselves, just to make  a compatible toolchain.

As to the internal shorts, I'd think that most of the power in the FPGA goes to dynamic losses. So if you have the whole chip bouncing around at 200MHz, 200 to 500mA is normal for a 5k gates cyclone. But static they draw close to nothing if they are static. So put the chip on a 40mA current-limit (or maybe even 20 or 10) and it becomes difficult to blow it up.

I agree that reverse engineering the bitstream shouldn't be too hard. On the other hand, things have become more difficult now bitstream files are no longer fixed length.

@ John B Above,

Yes, it's surprisingly easy to provide nice-looking documentation that lacks essential information when you start using it.....

Roger Wolff wrote:

 

John Beetem wrote:

  However, I've heard over the decades that the bit format is not that hard to reverse-engineer.  The problem is that if you publish the results you could be sued.

Reverse engineering for the purpose of making a compatible product (as opposed to competing!) is already legal in Europe. This overrules whatever EULA you signed or clicked when starting to use the product.

 

Of course they prohibit reverse engineering  in the EULA, and then hope you don't know the law.

 

If you're making a word processor that needs to read microsoft word files, the situation is a bit vague. You're replacing "microsoft word". But in the case of the FPGAs we're discussing we are NOT interested in selling FPGAs ourselves, just to make  a compatible toolchain.

Aha, that explains why the best work in reverse-engineering FPGAs came out of France.

It would be funny to call Slashdot authoritative, but for what it's worth, 15 years of articles and commentary (occasionally well informed) about IT-related law in the US very definitely suggest that reverse engineering for the purposes of interoperability is a legal activity in the US as well, dating all the way back to firm precedents set in the IBM vs Amdahl wars.

Matters got a little bit confused when the DMCA turned stupidity and vested interests into law, but if one excludes the minefield of reverse engineering that circumvents copyright protection, then reverse engineering continues to be as legitimate and legal an activity as ever, and extremely widely used in industry throughout the world, including in the US.

Morgaine Dinova wrote:

 

It would be funny to call Slashdot authoritative, but for what it's worth, 15 years of articles and commentary (occasionally well informed) about IT-related law in the US very definitely suggest that reverse engineering for the purposes of interoperability is a legal activity in the US as well, dating all the way back to firm precedents set in the IBM vs Amdahl wars.

 

Matters got a little bit confused when the DMCA turned stupidity and vested interests into law, but if one excludes the minefield of reverse engineering that circumvents copyright protection, then reverse engineering continues to be as legitimate and legal an activity as ever, and extremely widely used in industry throughout the world, including in the US.

I take Slashdot legal opinions with large chunks of salt, but I do read a lot of groklaw.net.  IANAL but I think the problem is with EULA rather than reverse-engineering per se.  If you reverse engineer a product with no help from the maker, that's probably OK.  OTOH, if you use Xilinx tools to reverse-engineer a Xilinx FPGA, you're in breach of contract because the EULA specifically forbids you from doing it, even if you're doing it to benefit Xilinx by opening up new markets.  And as far as I know, there's no practical way to reverse-engineer Xilinx FPGAs without using their tools.

I'm not so sure it works that way.  In general, a EULA cannot override the law of the land, in any jurisdiction.  If the law says that X is legal, then a company's lawyers may write a EULA that says "You can  use our tool only if you do not do X with it" (lawyers being the least professionally responsible "profession" on the planet), but that means little to nothing if by doing X you are not doing anything unlawful.

At most they could try a civil suit against you, but even that would be really difficult to win because they would first face the uphill task of trying to convince the court that there ever was a binding contract with balanced consideration on both sides to begin with, because a click-through EULA falls considerably short of being a proper contract.

And then even if that were achieved, there can be no claim for statutory damages so they would have to claim for actual damages, which would mean detailing them ... good luck with that.  This is really not a winning situation.

And then there's the whole quagmire of purchased vs licensed product ownership and use, and whether the manufacturer has any right at all to say what it done with it after purchase.  I don't know whether withdrawal of a user's right to use licensed software which is used to program a device which has been legally purchased has been tested in court, but it's a sure thing that the defendent will claim that the device is useless without the software and therefore use of the software is an integral part of the device purchased and cannot be withdrawn.

This is no simple area, and the only easy winners are the lawyers.

I'm not so sure it works that way.  In general, a EULA cannot override the law of the land, in any jurisdiction.  If the law says that X is legal, then a company's lawyers may write a EULA that says "You can  use our tool only if you do not do X with it" (lawyers being the least professionally responsible "profession" on the planet), but that means little to nothing if by doing X you are not doing anything unlawful.

At most they could try a civil suit against you, but even that would be really difficult to win because they would first face the uphill task of trying to convince the court that there ever was a binding contract with balanced consideration on both sides to begin with, because a click-through EULA falls considerably short of being a proper contract.

And then even if that were achieved, there can be no claim for statutory damages so they would have to claim for actual damages, which would mean detailing them ... good luck with that.  This is really not a winning situation.

And then there's the whole quagmire of purchased vs licensed product ownership and use, and whether the manufacturer has any right at all to say what it done with it after purchase.  I don't know whether withdrawal of a user's right to use licensed software which is used to program a device which has been legally purchased has been tested in court, but it's a sure thing that the defendent will claim that the device is useless without the software and therefore use of the software is an integral part of the device purchased and cannot be withdrawn.

This is no simple area, and the only easy winners are the lawyers.

I have the impression that in the EU there is an overruling law that states that reverse engineering is allowed, while in the US, a contract such as an EULA might overrule the default of reverse engineering is allowed (if nothing else is agreed upon.

EULAs are a tricky issue. We have a recent US court ruling that indicates that just having the licence on the web site doesnot mean that the user agreed to it. You have to force the user to click through it. "here it is, please read it and then click AGREE". I think there are plenty of cases that have ruled an EULA applicable. Even in the US, provided they forced the user to click through it. 

From memory, I think it was an EU directive that stated that reverse engineering is allowed for the purposes of interoperability, if the supplier does not make available (I think not necessarily for free unfortunately) a specification that allows interoperability without the need to perform reverse engineering. However I guess that doesn't mean that is the only time that reverse engineering is allowed. But I'm no expert.

In theory the directive is quite nice in that it encourages companies to publish an interface, rather than encourage reverse-engineering which may have the negative effect for companies that people may discover

proprietary skills/techniques that the product employs beyond the interface as a side-effect of working on

reverse-engineering the interface. i.e. better the devil you know, so just give the people the interface spec,

rather than encourage them to scratch a little too deep and find out proprietary secrets.