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.

In any event, my question was prompted by a much less ambitious goal, a desire to have (and to help in developing) an open source EDA tool that is able to read, design for, and program some elementary programmable logic device, no matter how old and basic, as log as it's still being manufactured and sold.  That's a far cry from other worthy goals like better quality than vendors' proprietary software or less bloaty or more efficient.

Nevertheless, it would be a start, and at least for some small projects and for some types of education, I'm sure that such open tools would be perfectly adequate, no matter how unimpressive the target device.  And from small seeds can grow impressive trees.

But to do that, one first has to identify some openly documented target device, and it seems that our list of possible candidates is empty at this point.

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 doubt that there is any future in an approach that relies on reverse-engineering a bitstream format.  All it would take is a small change in the format for the company's next device and you're back to square one.  While in principle your tool would still work for the old device as long as it remains in production, it's quite a bleak prospect, with no future path.

Maybe the idea is doomed until semiconductor fabrication can be done by enthusiasts / open community.

Morgaine Dinova wrote:

 

But to do that, one first has to identify some openly documented target device, and it seems that our list of possible candidates is empty at this point.

I've spent way too much time thinking about this over the last few days, and here are the best ideas I have so far:

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.

2.  As I suggested before, you could take a medium size FPGA, say a Xilinx XC3S200A, and use its LUTs as ROMs for storing logic functions and routing.  Xilinx documents how to update the contents of ROMs and registers (but not the routing).  Without a lot of effort, I think it's possible to fit in a 30-cell PLD with a simple, brute-force architecture that would permit simple tools.  Yes, you're only using a couple percent of the 200A's logic resources, but that's the nature of general-purpose computing: you spend a lot of energy getting data to the compute engines and very little doing actual computations.

The idea here is that students could get started with the PLD-within-an-FPGA with simple, clean tools that don't get in the way of learning about logic.  The students who blast through this and want to make something incredible can use the same FPGA development board and Xilinx tools to do big things, but you don't have to try to teach Verilog/VHDL and the Xilinx tool chain to everybody (including the instructors).  The US$55 XC3S200A-based XuLA-200 board form XESS  looks like a promising platform.  One thing very nice about this board is that the PIC that interfaces between USB and JTAG has GPL free-as-in-liberty software, so you can talk to it from any USB host, including RasPi, instead of being digitally handcuffed to an x86 host.  And if you want to add features like probing internal registers using JTAG you can update the PIC software with new features.

So there's a couple of ways to do this, and others may appear.  This means it's worth while to finish putting together that simple, clean CAD system I keep talking about.  We'll see what other platforms are ready when I have something working.

Morgaine Dinova wrote:

 

I doubt that there is any future in an approach that relies on reverse-engineering a bitstream format.  All it would take is a small change in the format for the company's next device and you're back to square one.  While in principle your tool would still work for the old device as long as it remains in production, it's quite a bleak prospect, with no future path.

 

Maybe the idea is doomed until semiconductor fabrication can be done by enthusiasts / open community.

The basic problem is that the vendors see no advantage in opening up their formats to the world, and a number of disadvantages.  They like to tell prospects that their format is double-secret-has-never-been-hacked, or else prospects fear that their designs will be stolen.  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.

Now that the principal Xilinx and Altera patents have expired, maybe an Asian semiconductor manufacturer will create a line of cheap FPGAs with an open bitstream so they don't have to write tools.  The problem is that nobody will buy the parts until there are tools, and nobody will create the tools until there are parts (or at least an architecture).  If it were as cheap to make ICs as PCBs or 3-D printed thingummies, the open community could do this themselves.  Actually, it is cheap to make ICs -- just use an FPGA and the vendor's tools, so there's not really an incentive to do this.

So here's my plan: make that simple, clean CAD system and target whatever I can, be it Cypress PSoC5 or PLD-within-an-FPGA.  This at least gets the tool ball rolling, and I'll have the fun of helping kids get into logic.  "Logic!  Why don't they teach Logic in these schools?" asks the Old Professor in The Lion, the Witch, and the Wardrobe.

And who knows?  Maybe reverse-engineering for the purpose of using a manufacturer's product for the purpose intended by the manufacturer will become legal -- at least in some country -- and the bitstream formats will become legally hackable.  Or one minor vendor facing bankrupcy will open their format as a "Hail Mary" pass, and the others will fearfully follow.  After all, who expected Broadcom to open-source their OpenGL "driver"? 

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.

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.