FPGA EEVBlog segments / Xilinx buyer's remorse

[rs20]

Now I know Dave's busy, and he doesn't need to explain anything because he's always got many things on his plate, but there was mention of some FPGA segments for the EEVBlog. I wonder if licencing/development issues stunted that idea, for the same reason that he's indicated that he won't do Altium Designer tutorials. (Note -- I fully 100% support this reasoning -- no point doing hobbyist videos that start with "fork out a few hundred dollars" as step 1).

Many (specifically, six) years ago, I bought a Xilinx Spartan-3E starter kit for a hobbyist-friendly $180 or thereabouts. I opened it up, played with it for a bit, and discovered that the software that came with it was an evaluation that expired after some set period.  This disillusioned me, and put me off playing with it any further once that period elapsed.

Fast-forward to 2014, and I find this thing sitting in the cupboard and I think to myself, "I was young back then. Maybe I misunderstood the licence period issue, maybe I can still develop with this thing." So I download Xilinx ISE Webpack (or something), and 6GB and only a little effort later, I've implemented and tested a circuit of mind-blowing complexity two NAND gates! Hooray! Now, on to the most important part of most (?) FPGA projects: the soft-core. It strikes me that most FPGA solutions (indeed, most digital circuits these days) require some kind of CPU somewhere to oversee the operation of the system (whether it be a dedicated MCU/CPU, or a soft-core onboard the FPGA). This is the bit that stuns me: in order to use Microblaze, Xilinx's soft core, I apparently have to shell out $500+ for a Xilinx EDK licence. I just can't justify that for playing around; but if I can't play around, I can't discover what this board is capable of. In other words, it's a $180 catch-22 doorstop.

This Spartan-3E starter kit has the unenviable distinction of being the only thing I've ever bought that has hit me with buyer's remorse twice.

What's particularly perplexing to me is that Xilinx makes less than 5% of its revenue* from development tools. How does this even make sense as a corporate strategy? Even well-implemented licencing systems** create road-blocks for everyone involved. It must cost money for them to maintain a licencing system, it'll cause no end of headaches and lost productivity amongst the companies using Xilinx tools, and any companies out there using Altium tools won't be able to freely experiment with Xilinx tools. Does it really make sense to suggest that the increased adoption of Xilinx FPGAs resulting from a free*** software ecosystem might be less than the 5% increase in hardware revenue it'd take to cover the hypothetical total loss in software revenue?

Time to turn this rant into a pragmatic question. Has anyone succeeded in developing a Xilinx FPGA solution with a soft-core without forking out hundreds? How? Eval licenses and vouchers with dev boards don't count. Can you generate 30-day eval licences over and over again, or does it only allow one eval per product per MAC address?


* Source -- and they've got a healthy margin on hardware production costs, so this can be translated as very approximately 5% of profit.
** the Xilinx licence system involves receiving licences by emails and having to download and manually install them, so not well-implemented then
*** Free as in beer.

[jeremy]

I hear you. Not only do you pay through the nose for the IC, it's then a big chunk of money for the dev tools (which are pretty counterintuitive anyway...)

I have been planning to try this: https://github.com/m-labs/lm32 but haven't got around to it yet. I know the MiSoC guys have it working though.

Oh, and the LM32 has gcc support

edit: http://www.xilinx.com/products/intellectual-property/picoblaze.htm ?

[hamster_nz]

Hi RS20.

The 'free' stuff is out there, you just have to look away from the vendor's own solutions  - the exception being http://en.wikipedia.org/wiki/LatticeMico32, which can run on pretty much any FPGA (not sure if you actually should be doing that though!).

Have a look at  ZPUino http://www.alvie.com/zpuino/ - 32-bit micro with an Arduino interface.

I've also played around with the AVR8 core (http://papilio.cc/index.php?n=Papilio.ArduinoCore), and put a character mode VGA interface onto it. Might be a good use case for those who like the Arduino /  AVR stuff.

I've ported socz80 (http://sowerbutts.com/socz80/) to a new board in an evening for that old time CP/M feel - however a 125MHz Z80 with 8MB RAM is a bit OTT.

Mike

[mikeselectricstuff]

A processor is a fairly inefficient use of FPGA resources, which is why we are now starting to see embedded ARMs.
Unless you have the spare FPGA space available (e.g. you need the pin count, which dictates die size) it will often be cheaper and simpler to use a seperate processor.

As regards EDK, a while ago there was a devboard that came with a version of EDK that was locked to the device type on the board - not sure of there was any time or other limitations on this. 

[nctnico]

Look at the LM32 softcore from Lattice. I recently did a project with that softcore on a Xilinx Spartan 6 using the free Xilinx Webpack ISE 14.7. It has GCC toolchain support. All in all it is pretty cool.

http://www.ohwr.org/projects/lm32
http://blog.tkjelectronics.dk/2011/02/porting-the-latticemico32-to-a-xilinx-fpga/

[FrankBuss]

There are dozens of CPUs on http://opencores.org/projects Usually they are not as well integrated as the ones from Altera or Xilinx and mostly without debugger, but many of the projects provides a toolchain to compile C code and if you don't need much memory, using the internal BRAM of the FPGA makes it even easier to use it. And can be interesting to look at the source code to see how it works or even modifiy the core.

But as Mike said, a softcore is inefficient on FPGAs. Good for playing with devkits, but if you design a product, you can get a small ARM microcontroller for some dollars, which would require a FPGA costing hundreds of dollars. Use FPGAs for high speed, high IO and time critical tasks, and an additional microcontroller for the rest.

[nctnico]

A seperate controller is easier for development but let's remember that the first Rigol scopes used the Microblaze softcore. A softcore in an FPGA is not very efficient indeed but you can greatly accellerate lots of stuff. If you attach a DMA engine to the softcore you can create extremely fast memcpy (memory to memory copy) and memset (initialize memory) functions. The same goes for things like CRC, a-law/u-law, JPEG compression, etc, etc.

[rs20]

Thanks for the awesome responses everyone! Looks like LM32 (which I hadn't heard of) is getting a lot of upvotes; it looks quite impressive. I like how it's configurable, and it's got the whole wizard thing going on (I'm a Makefile kind of guy, but sometimes I just need that wizard for baby steps...). Seems like there's some difficulty on running it on a Spartan-3E (I don't even know how many LUTs I have, I should look that up) but apparently it can be done with some degree of tinkering. I now have a warm fuzzy feeling towards Lattice.

I know half my LUTs are going to be burned on the soft-core which may be a bad idea in an end-use scenario, but it should be good for initial playing around with the devkit. I don't have a particular project in mind (except, of course, for the classing FPGA 'Hello World': VGA pong), but when I reach that stage I'll definitely look into getting a chip/devkit with a hard core (whether or not it shares a package with the FPGA). The Xilinx Zynq parts look amazing (and almost certainly too high-end for anything I'll ever do), but last time I really shopped around for FPGAs was 2008 so it's probably run-of-the-mill by now...

Has anyone dealt with FPGAs on their own PCBs? The other pain point is those BGA packages... I've seen some 1mm pitch BGA packages that might be hot-air-gun friendly? I need to play with CPLDs too *mind explodes*

[Scrts]

They have changed the politics now.
If you'd buy ZedBoard, they would include a device-locked license, so you can do anything you want on that board.

Anyway, I am Altera guy... I've started with the same Spartan-3E board you had, but the MIG (Memory Interface Generator) was terrible back then. Also Virtex-4 PCI-e hard ip had longer errata sheet than its datasheet. Switched to Altera pretty fast.

Now my work requires to go back to Xilinx again Hopefully, they've made some improvements.

[FrankBuss]

Right, the Zynq chips look interesting. I think the Parallella board is one of the cheapest devkits you can get with it, and it has this parallel thing chip, too. I got mine from the Kickstarter campaign, now I need some time to play with it

Has anyone dealt with FPGAs on their own PCBs? The other pain point is those BGA packages... I've seen some 1mm pitch BGA packages that might be hot-air-gun friendly? I need to play with CPLDs too *mind explodes*

You can get many FPGAs as TQFP, too. I used a MachXO2 for my Crazy Cartridge prototype. Easy to solder, and some versions need just one 3.3V supply voltage and have integrated configuration flash, like a CPLD, but which is updatable from within the running FPGA. Pretty nice chips for smaller projects.

[mikeselectricstuff]

Right, the Zynq chips look interesting. I think the Parallella board is one of the cheapest devkits you can get with it, and it has this parallel thing chip, too. I got mine from the Kickstarter campaign, now I need some time to play with it

Has anyone dealt with FPGAs on their own PCBs? The other pain point is those BGA packages... I've seen some 1mm pitch BGA packages that might be hot-air-gun friendly? I need to play with CPLDs too *mind explodes*

You can get many FPGAs as TQFP, too. I used a MachXO2 for my Crazy Cartridge prototype. Easy to solder, and some versions need just one 3.3V supply voltage and have integrated configuration flash, like a CPLD, but which is updatable from within the running FPGA. Pretty nice chips for smaller projects.

It is sometimes possible to do QFPs on 2 layers - one thing I like about the Lattice XO2 is the onboard core voltage regulator, so you only have one rail to route, which you can do under the chip. Dual rails can sometimes be doable but depends on the location of the pins. A nice thing about FPGAs is you have huge flexibility on pin placement, which greatly simplified PCB layout.

[marshallh]

If the first thing you try with an fpga is do a softcore... You're doing it wrong

Worry about that later once you know what you're up to

[nctnico]

The biggest problem with QFP is that the larger FPGAs are not available. Putting a QFP FPGA on a 2 layer board is very doable. I usually have the various supply voltages as rings underneath the FPGA on the top layer. A short trace goes to the pin and a decoupling capacitor from the pin to ground does the rest. The trick is to keep the bottom layer as a mostly solid ground plane. The freedom of choice for the pins (beware some pins can be input only) allows for very clean PCB layouts.

[Bassman59]

Now, on to the most important part of most (?) FPGA projects: the soft-core. It strikes me that most FPGA solutions (indeed, most digital circuits these days) require some kind of CPU somewhere to oversee the operation of the system (whether it be a dedicated MCU/CPU, or a soft-core onboard the FPGA).

My guess would be that many professionals start to think, "Oh, it would be great to integrate a soft-core processor into the FPGA ..." and then they actually do it once, and realize that it's a disaster for a whole lot of really good reasons, and never do it again.

Really Good Reasons include: vendor-provided cores changing with each tools release for No Good Reason, vendor deprecating one processor bus for another for No Good Reason, vendor-provided IP cores that are buggy and/or have poor performance, tool chains that are cantankerous, etc.

Another really good reason is that you can use a less-expensive FPGA next to a standalone processor and have the whole solution be a lot less expensive than the processor-in-FPGA.

This is the bit that stuns me: in order to use Microblaze, Xilinx's soft core, I apparently have to shell out $500+ for a Xilinx EDK licence. I just can't justify that for playing around; but if I can't play around, I can't discover what this board is capable of. In other words, it's a $180 catch-22 doorstop.

Well, I have that board, and it's quite capable of doing a lot of things without a having a processor. Many FPGA designs simply don't need a sequential-execution C-programmable processor.

Having said that, certainly Xilinx could have chosen to give away the EDK, but I have to ask: why? For companies who do that kind of work professionally, the cost of the license is in the noise. (It would be nice if the cost of the license included real support, though.)

[rs20]

If the first thing you try with an fpga is do a softcore... You're doing it wrong

Worry about that later once you know what you're up to

Read my original post, I have done my two NAND gates, so I'm ready for soft cores! (Jkz)

But seriously, as I hint at below, I've never had a moderately interesting digital PCB without a micro on it, so I can't currently conceive of doing a moderately interesting digital solution without a sequential processor of some sort. As my dev kit doesn't have a standalone MCU, I have no choice.

This is the bit that stuns me: in order to use Microblaze, Xilinx's soft core, I apparently have to shell out $500+ for a Xilinx EDK licence. I just can't justify that for playing around; but if I can't play around, I can't discover what this board is capable of. In other words, it's a $180 catch-22 doorstop.

Well, I have that board, and it's quite capable of doing a lot of things without a having a processor. Many FPGA designs simply don't need a sequential-execution C-programmable processor.

Enlighten me: how do you drive that LCD without a sequential-execution processor? It seems to me that converting integers to decimal, performing string processing, and iterating through each char and pushing it out to the LCD would be incredibly obtuse to write in Verilog/VHDL. Am I wrong/missing something? I agree in principle, I want to avoid using a soft core if there's a reasonable way of avoiding it.

Having said that, certainly Xilinx could have chosen to give away the EDK, but I have to ask: why? For companies who do that kind of work professionally, the cost of the license is in the noise. (It would be nice if the cost of the license included real support, though.)

You're exactly making my point: the cost of the licence is noise to both Xilinx and the purchasing company, but the impediment to developement/pain-in-the-backsideness of dealing with licenses is not (I claim). It seems like a lose-lose for all involved.

[SirNick]

For companies who do that kind of work professionally, the cost of the license is in the noise. (It would be nice if the cost of the license included real support, though.)

I don't know that I've ever worked at a shop where something with what should be a trivial cost, wasn't still a pain point.  I don't work in the EE industry, so while things could be different, I recall once ordering six Sun database servers, and finding no one that would allocate enough from their budget to buy a sack of RJ-45 ends to cable them up.  Similarly, management wouldn't conceive of using free software that would remove the need to license a Windows server on every CPU in a VMware cluster, while we also had to buy support contracts for secondary hardware because it was easier to pay $10,000 once a year than $250 to replace a PSU if it failed.

Ridiculous?  Yeah, absolutely.  But man.. you can't tell me there hasn't ever been a workbench with a crate full of FPGAs still sealed in their anti-static bags, and no one willing to spend money on a license to use them.  That $500 is gonna stick in someone's craw.  If it isn't a major profit center, it just makes no sense.

[hamster_nz]

Enlighten me: how do you drive that LCD without a sequential-execution processor? It seems to me that converting integers to decimal, performing string processing, and iterating through each char and pushing it out to the LCD would be incredibly obtuse to write in Verilog/VHDL. Am I wrong/missing something? I agree in principle, I want to avoid using a soft core if there's a reasonable way of avoiding it.

I made a Reflow Controller for a domestic toater oven using a FPGA with:
- Fully stand-alone operation - with a USB power pack
- A reasonable amount of control over the heating profile within the design (e.g. ramp up, soak, peak and so on)
- RS232 serial interface to host for logging - updates every second.
- 4-digit seven segment display, with intellegent autoscaling
- Thermocouple ADC interface using a MAX31855

All without any soft CPU. Sure, I could have grabbed an Arduino and a few libraries, but what is the fun in that?

The big problem with most HDL development is that unless you use pre-designed parts then you have to do it all yourself. No Arduino user would need to or bother reading the datasheets or studiying the timing diagrams, we just borrow use somebody else's library. With FPGAs you are designing logic to talk directly to the chip, so that stuff on the datasheet matters - setup times, hold times, max/min clocks, command latencies...

There are a lot of things you can do in HDL that make what seems stupid to do in software actually a reasonable solution.

If you have a 6 digit decimal display that needs updating once per second? If so, you don't use division - you can just count in decimal and binary at the same time to do the conversion in under 1,000,000 cycles. Or if you want to do it quicker, count off the thousands and then the units, it will use a little more logic, but will do it in 2,000 cycles.

Or you can use this non-obvious solution http://www.eng.utah.edu/~nmcdonal/Tutorials/BCDTutorial/BCDConversion.html, and convert the number in about 20 cycles, in what would be completely silly way to do it in software.

I guess I am trying to say that early on in your HDL experiments everything is hard, even if you are an experienced programmer. Can you remember how hard it was to first convert a number to ASCII without using a library function? Or how hard it was to print out a string backwards?

That is how hard you should expect using a HDL to be, until you build up the the experience to follow your gut instinct to the solution.

[Someone]

Enlighten me: how do you drive that LCD without a sequential-execution processor? It seems to me that converting integers to decimal, performing string processing, and iterating through each char and pushing it out to the LCD would be incredibly obtuse to write in Verilog/VHDL. Am I wrong/missing something? I agree in principle, I want to avoid using a soft core if there's a reasonable way of avoiding it.

Well you probably don't need a 32 bit processor running at 100MHz with MB of ram to do that processing. The picoblaze from Xilinx is free, and they had a tiny fixed config microblaze for free at one point.

But those tasks are easy enough to do in the FPGA using a series of state machines (the fundamental building block of most FPGA systems). Probably best you buy a book or find a online course focused on FPGA design and work through that.

[jeremy]

Enlighten me: how do you drive that LCD without a sequential-execution processor? It seems to me that converting integers to decimal, performing string processing, and iterating through each char and pushing it out to the LCD would be incredibly obtuse to write in Verilog/VHDL. Am I wrong/missing something? I agree in principle, I want to avoid using a soft core if there's a reasonable way of avoiding it.

I made a Reflow Controller for a domestic toater oven using a FPGA with:
- Fully stand-alone operation - with a USB power pack
- A reasonable amount of control over the heating profile within the design (e.g. ramp up, soak, peak and so on)
- RS232 serial interface to host for logging - updates every second.
- 4-digit seven segment display, with intellegent autoscaling
- Thermocouple ADC interface using a MAX31855

All without any soft CPU. Sure, I could have grabbed an Arduino and a few libraries, but what is the fun in that?

The big problem with most HDL development is that unless you use pre-designed parts then you have to do it all yourself. No Arduino user would need to or bother reading the datasheets or studiying the timing diagrams, we just borrow use somebody else's library. With FPGAs you are designing logic to talk directly to the chip, so that stuff on the datasheet matters - setup times, hold times, max/min clocks, command latencies...

There are a lot of things you can do in HDL that make what seems stupid to do in software actually a reasonable solution.

If you have a 6 digit decimal display that needs updating once per second? If so, you don't use division - you can just count in decimal and binary at the same time to do the conversion in under 1,000,000 cycles. Or if you want to do it quicker, count off the thousands and then the units, it will use a little more logic, but will do it in 2,000 cycles.

Or you can use this non-obvious solution http://www.eng.utah.edu/~nmcdonal/Tutorials/BCDTutorial/BCDConversion.html, and convert the number in about 20 cycles, in what would be completely silly way to do it in software.

I guess I am trying to say that early on in your HDL experiments everything is hard, even if you are an experienced programmer. Can you remember how hard it was to first convert a number to ASCII without using a library function? Or how hard it was to print out a string backwards?

That is how hard you should expect using a HDL to be, until you build up the the experience to follow your gut instinct to the solution.

Right, but this seems like it is probably a very inefficient way to do it. For the features you described, doing everything (plus PID) with a microcontroller is almost trivial. While I do appreciate you were doing this for fun, I think the OP is looking for the simplest solution possible.

If for example, you are doing some complicated filtering of some ADC signal in the fabric and then you just want a way to display a graph on a graphic LCD module and log the results to an SD card, I think that a soft core would be a very good idea? Doesn't really make sense to write a whole bunch of verilog to do that (at least to me anyway), when you can quite simply and easily do it in C

[miguelvp]

Surely you can do sequences in HDL, you cant avoid being sequential in most cases. For the LCD you have a pixel count that increments every clock, that's your memory buffer address and position in the screen. Sure you can do things in parallel but most of the times everything is a sequence of events, and you can't get to the next event until the previous one is done.

Otherwise I would do all my coding in VHDL if it only took one cycle to get the final result

You don't need a soft core to drive an LCD or access memory etc..

Edit: and you don't have to use counters or state machines either (although they are better) you can just program sequences that will execute one after the other and you can put delays between them if needed.

[jeremy]

Sure you can use the graphic LCD, but I'd hate to be the person who has to implement graphic lcd *and* SD card (with FAT) support in a HDL.

[miguelvp]

Sure you can use the graphic LCD, but I'd hate to be the person who has to implement graphic lcd *and* SD card (with FAT) support in a HDL.

Why do you hate hamster_nz, he has done that and more I believe

[hamster_nz]

All I've done is read blocks from an SD card.... only a nutter would build a FAT state machine.

Let me see... read partition table... read block zero... jump ahead to the directory... look for file.... jump back to fat table... follow cluster chain.... stream audio....

Yeah.... nah. CPUs have some use!

[mikeselectricstuff]

Some people seem to be losing sight of when you should use an FPGA, i.e. when it's too time-sensitive to do on a processor. If you can do it on a processor, then do so - only do stuff in HDL when the processor can't do it fast enough, or when an MCU's I/O isn't a good fit for the interfacing requirement.
Writing a UI or FAT file system in HDL would be ridiculous, but in these examples an FPGA could help accelerate things, to render fonts to an LCD, or handle the raw datastream from an SD card once the FAT software on the MCU has worked out which sectors to read. (Actually I think a read-only FAT SD card implementation wouldn't be that hard to do in an FPGA, but writes would get very messy very quickly)
HDL is much harder to write and debug than code.  Everything you do in HDL takes up far more physical space on silicon than code in flash, so you should only use FPGA resources where necessary.
In most cases an external MCU+FPGA will give the best balance between cost, power, and development effort. There will be cases where it makes sense to put the MCU on the FPGA, e.g. if you need tight coupling or a small MCU in a big FPGA, but I suspect these will represent a small minority of applications.

Something else to consider is that you will often want a way to update the FPGA config - having a seperate MCU to handle this, not dependent on the FPGA to operate, will make this a lot easier.

Another approach that can be appropriate in some cases, if you have some spare block memory, is to use this as ROM to implement a simple sequencer to do some sequential type stuff, though you may need to write your own tools to generate the data.
 
 

[amyk]

All I've done is read blocks from an SD card.... only a nutter would build a FAT state machine.

Let me see... read partition table... read block zero... jump ahead to the directory... look for file.... jump back to fat table... follow cluster chain.... stream audio....

Yeah.... nah. CPUs have some use!

Essentially you would be implementing most of a CPU if you tried that...  which isn't necessarily a bad thing, some people like the challenge after all; but I agree with everyone else here saying that FPGAs are not the best way to do this.