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.

The question is: Should VHDL simulators run so slowly as they do? I think not.

SHOULD a VHDL compiler require a big computer? I think not.

If say I want to calculate pi to 1 billion decimal places I inherently need around 1Gb of memory. Or 512Mb if I go BCD. But as FPGA configurations fit in a few megabytes even for quite large ones, there is no inherent reason to that an FPGA compile needs to use large amounts of memory.

The vendor's FPGA tools have become big clunky pieces of software because they were incrementally developed by lots of different programmers.

A good Open source redesign would yield a much sleeker program.

@Roger,

As you protest that an open source FPGA design toolset would be so much better than the efforts made by several different teams of pretty good people in the FPGA industry I'm reminded of  a passage from Jane Austen's Pride and Prejudice:

During a discussion about playing the piano, Lady Catherine remarks, “If I had ever learnt, I should have been a great proficient.”

Michael Kellett

Michael Kellett wrote:

 

To learn basic digital logic there is nothing to beat gettting going with a breadboard and  a handful of 74 or 4000 series chips. You can see all the nodes with a cheap scope and you don't need any other tools except a pencil and paper. If you have the determination you can make some interesting stuff.

While you are most certainly entitled to your opinion, the first thing I thought of when reading your comment was "you're living in the past, man".  I've designed logic that way, and IMO it's a PITA compared to a good simple clean CAD system with an FPGA target.  With a breadboard, if you make a mistake you have to rip up and reconnect the wires, and it's way too easy to hook up the wrong wire.  Any significant project is going to end up with a nasty rat's nest.  In comparison, with a good simple clean CAD system a learner can make nice logic diagrams and/or write Boolean equations and play with them on the screen to get a good idea whether the design works before downloading to an FPGA to press real Springwerk and watch actual Blinkenlights.

N.B. I don't know of any good simple clean CAD systems available at this time.  Most FPGA design systems available from vendors are very complex and IMO quite daunting to someone trying to learn logic, and each release gets more complex.  JMO/YMMV

Yeah, in Dutch we have the saying "De beste stuurlui staan aan wal". Litterally the best shippers are on the shore, meaning it is easy to critisize those who actually have to DO it.

And I'm sure there would be a few "snags" to work out when you'd do things again. Some of which would require more memory than I'd guess now. But having seen Quartus start up, you know immediately that there is too much bloat, as just the gui alone already takes a gigabyte of memory.

A design program like eagle has a commandline. Most don't use that. But it makes sense for design programs like eagle, mentor chip design and quartus. That means that your gui can remain quite lightweight. In eagle for instance, the gui need only startup a "show the current schematic" subprogram if the "schematic" window is open.

@John,

I don't advocate breadboarding as a cost effective way of designing complex logic for commercial purposes but it is still a good way to learn. Simulating on paper and  implementing with physical parts teaches many lessons - not the least of them that thinking before doing can save a lot of time. Although many of my designs use FPGAs I still use gate level logic chips from time to time - it isn't the past yet.

@Roger,

I was teasing you of course and happy to learn the Dutch way of saying it !

I agree that the vendor systems do seem very bloaty - I use Aldec HDL for design/simulation (about 300Mbyte install image) and Lattice Diamond for synthesis/debugging (2Gbyte zipped install image). There is a lot of overlap - Diamond actually includes a version of the Aldec tool and the Aldec tool loads up its own versions of the Lattice libraries.

I find the Lattice toolset to be the easiest to use (which might just be familiarity) of the vendor tools I've tried - it's certainly no more daunting to use than running Linux !

Michael Kellett

Michael Kellett wrote:

 

With regard to open source tools - as far as I can tell there aren't any worth using and the tools from the FPGA vendors need big computers to run, Linux is no problem but you need lots of RAM and lots of hard disk.  No one in their right mind would want to run a VHDL simulator...  So we may as well accept the world as it is, and right now that means FPGA simulation and compilation on a PC or MAC.

Digital CAD tools, including FPGAs, used to be my main research area a couple of decades ago.  I ran into a lot of really smart people who could have done amazing things with FPGA tools and FPGA applications if they hadn't been locked out by the vendors.  Sure, you can create generic algorithms and architectures and publish papers about them, and even get tenure doing such things, but it's nowhere as much fun as making things that really work so the kinds of visionaries who need that thrill will quite simply work on something else.

Xilinx does a good job with their tools, and with skill you can write Verilog that will produce hardware that's reasonably close to what you want.  OTOH, if you make a minor change to the Verilog and suddenly the tools want an extra 20 LUTs, good luck trying to track down what the synthesizer did.

I once asked an obnoxious question at an FPGA workshop related to whether it's a good idea for a silicon vendor to insist that you only use their tools.  I asked the group "How many of you have used an Intel processor?"  (Everybody raised their hands.)  Then I asked "How many of you have used an Intel compiler?"  (Maybe one or two hands -- who remembers PL/M?)

In terms of accepting the world as it is, I'll quote GBS:

George Bernard Shaw wrote:

 

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself.  Therefore all progress depends on the unreasonable man.

 

... or unreasonable woman, of course.

Michael Kellett wrote:

 

@Roger,

 

As you protest that an open source FPGA design toolset would be so much better than the efforts made by several different teams of pretty good people in the FPGA industry I'm reminded of  a passage from Jane Austen's Pride and Prejudice:

 

During a discussion about playing the piano, Lady Catherine remarks, “If I had ever learnt, I should have been a great proficient.”

Nice quote!  But the FPGA lockout reminds me of two lines from Tom Lehrer's "Whatever Became of Hubert":

Tom Lehrer sang:

 

Second fiddle's a hard part, I know,

When they don't even give you a bow.

For the record, I'm not saying open source tools would have better quality than vendors' tools.  I'm saying opening the programming bit streams would open up new applications (such as seriously-reconfigurable computing) and allow far more people to learn about FPGAs and become proficient in using them, resulting in far more FPGA chips being sold.

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.

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:

 

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"? 

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 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.