Implementing something in the FPGA vs microcontroller/processor...

[alank2]

So having played with an FPGA for about a week now and making some changes to a SD controller so it will work with SDHC cards as well as SD cards.  I was actually modifying it based on Chan's FATFS SD initialization example.  This change increased the size of the sd module considerably to where it barely fits the FPGA now.

Today while driving around it occurred to me that this logic, initializing the SD/SDHC could be moved to the bios instead (which is running on a Z80 in the FPGA).  If the FPGA interface just allowed for controlling the SS line on the SD Card and provided a way to send a byte and receive a byte, then it could be much less complicated than the way it is implemented now which is more like disk devices were implemented at the time (3 register bits, 8 data lines, a n_RD and n_WT signal).  So, the FPGA could handle what it needs to (SPI) and the bios could handle what it needs to (card detection, sd/sdhc, lba calculations, etc.).  The bios would be a bit bigger, but the fpga resources would be considerably less.

My question is, where does it make sense to implement something in fpga logic vs. microcontroller/processor code.  Are there any schools of thought or best practice ideas on this?

[westfw]

The FPGA can do hardware things MUCH faster.  So fast that I've never been motivated to use one :-(

[ebclr]

If you want you can do one or more processor inside the fpga, Fpga is pure logic, it's something like a programmable hardware

Take a look on this site http://www.fpga4fun.com/

http://opencores.org/

http://www.ni.com/white-paper/6984/en/

[Someone]

The FPGA can do hardware things MUCH faster.  So fast that I've never been motivated to use one :-(

Faster is not the best way to describe it, FPGA systems can have extreme throughput through parallelism and pipelining.

If it needs throughput that sequential processing cannot provide then it needs to go in FPGA fabric (or an ASIC). The power is that the FPGA fabric can implement sequential processes which can take up less space than a fully pipelined design so you can directly trade off throughput for resources. The extreme end example is one of the tiny "softcore" FPGA processors such as picoblaze bit banging IO and doing complicated decision making which is what the OP is describing.

As to when its needed thats the challenge of engineering tradeoffs, there are no hard and fast rules or examples. But if you've used a large amount of your resources for a minor feature, then its certainly time to reassess what went wrong.

[uncle_bob]

Hi

Look at the cost.

You can get an MCU that will do an SD card interface for less than a dollar. An FGPA will run you much more. If you *can* do it with a simple MCU, it likely will be cheaper / easier done that way. If you have to go to an FPGA for speed ... that's where they shine.

Bob

[jbb]

Hi all

My personal yardstick is to ask 'can I reasonably do this with a microprocessor?' If the answer is yes, use a micro.

You should bring out the FPGA when you need things like:

• Absolutely minimum latency
• Deterministic timing
• Custom communications protocols at the bit/frame level, where standard microprocessor peripherals just won't work.
• Processing of great floods of data
• Mathematical operations which can be done in highly parallel or highly regular ways, e.g. matrix transformations, FFTs, digital up/down conversion (aka digital RF mixer), filtering

FPGA timing can be excellent because no resources are shared - that logic just sits there waiting to do its thing.  In contrast, a microprocessor would have to wait for an interrupt service routine or Operating System context switch.

FPGAs are not so good at situations where there are heaps of special weird cases, such as working with file systems, handling text etc.

The best results can come from a combination of custom logic and software.  For example, consider a UART receiving messages.

A typical microprocessor UART generates interrupts when characters come in (OK, some have FIFO buffers which help).  The microprocessor then has to:

• buffer the characters in RAM (triggers many interrupts, could use thousands of cycles for a 1kB packet)
• check for length (or whatever)
• run a CRC (can be slow if done in software)

... and then the software does the thing you actually want.

In contrast, an FPGA can:

• buffer the characters to a private bit of block RAM (no CPU interrupts yet), which is memory mapped into the IO space of the processor
• check for length
• check the CRC
• check whether the message is addressed to this node
• trap & execute a small number special messages (e.g. emergency stop) directly in hardware
• request one interrupt

... and then the software does the thing you actually want.  This way you get the best of both worlds - very fast & predictable performance for the time-critical messages, and the flexibility of software for less time-critical messages.

This inevitably leads to a question about soft-core processors.  Specifically, "I can get a better microprocessor for less money in solid silicon, so why should I implement a slower, more power-hungry, more expensive soft-core processor?" There are two answers:

• If you're already paying for an FPGA, you might be able to fit that processor in for free.  Also you'll save board space.  And the aggravation of interconnect (32 bit memory bus, anyone?)
• Get yourself a System on Chip (SoC) with hard silicon processors and FPGA logic, like the Xilinx Zynq or Altera SoC line.  That way you get substantial processing power (dual core ARM @ 665 MHz - quad core ARM @ 1GHz) in hard silicon.

jbb

[Muxr]

FPGA is well suited for state machines, where you need low latency real time processing and/or parallelism. MCUs are well suited for general purpose turing complete programs.

Typically if you can get away with it, you should use an MCU instead of an FPGA. Because MCUs are cheaper. Typically you use FPGAs for low level fixed function hardware operations, while you would use MCUs for your actual software.

The lines get blurred a bit because you could implement MCUs inside of an FPGA provided you have enough gates on it.. and some MCUs also have DSP capability which is similar to FPGAs. But in general if your MCU will do the job, there is no need to resort to using an FPGA.

For some example applications of FPGAs watch some of Dave's oscilloscope teardowns and you will see a lot of FPGAs in them. And you will notice they are typically used for dealing with high speed real time data. Things like sampling and processing large amounts of data from acquisition side of the instrument, something an MCU would struggle with. While MCUs and processors take this "rolled up/summarized" data FPGA crunches and display it on your screen for instance.

[legacy]

I love the idea behind the TPU (time process unit) introduced by Motorola for their MC683xx chips, the TPU is a programmable device with "slices" that can cooperate in parallel without the need of CPU, they are independent units: brilliant idea by Motorola, unfortunately ... it was complex to be programmed, and it's dead 

In my last experience I used four TPU channels (those slices are called "channels"), two channels were used as PWM generators, and two channels were used as UART

it was so complext that I needed to study the TPU-UM, which also comes with a special assembly compiler TPU-AS

anyway, in order to use those channels, I just needed to "upload" the configuration bit-stream from the MPU to the TPU: doesn't it sound like already heard?

with fpga, you upload the configuration

[uncle_bob]

I love the idea behind the TPU (time process unit) introduced by Motorola for their MC683xx chips, the TPU is a programmable device with "slices" that can cooperate in parallel without the need of CPU, they are independent units: brilliant idea by Motorola, unfortunately ... it was complex to be programmed, and it's dead 

In my last experience I used four TPU channels (those slices are called "channels"), two channels were used as PWM generators, and two channels were used as UART

it was so complext that I needed to study the TPU-UM, which also comes with a special assembly compiler TPU-AS

anyway, in order to use those channels, I just needed to "upload" the configuration bit-stream from the MPU to the TPU: doesn't it sound like already heard?

with fpga, you upload the configuration

Hi

Actually the Freescale ( = Motorola) people have the same thing in some of their modern ARM based products. Still complex to program, still "gee I need one more channel".

Bob

[mikeselectricstuff]

FPGA timing can be excellent because no resources are shared

And the flipside is that because resources aren't shared, every function you do in the FPGA consumes resources, which will eventually fill up the part. 
Where you have an MCU and an FPGA, you should normally do as much as possible on the MCU as it's easier to design & debug, and much, much cheaper in terms of resource usage.


 

[antti]

yes, from resources adding an soft-processor IP core and moving slow tasks into software in most cases SAVES fpga resources.

i2c HOST is one example that ist way easiest to implement as bit bang in sw

SD Card init is another example, in one case I used Actel ABC softcore to just do the sd card init (sd mode) before handoff to the sd card streaming interface implemented in the fpga logic

[obiwanjacobi]

An SD-card should be very easy to get working on a Cypress PSoC5...

Nice IDE too.
[2c]

[bingo600]

yes, from resources adding an soft-processor IP core and moving slow tasks into software in most cases SAVES fpga resources.

i2c HOST is one example that ist way easiest to implement as bit bang in sw

SD Card init is another example, in one case I used Actel ABC softcore to just do the sd card init (sd mode) before handoff to the sd card streaming interface implemented in the fpga logic

Antti L ?
Long time no hear.

Very nice to have you here 

/Bingo

[antti]

itsme, bit busy, my todays DONE List:

1) testing new low power Artix board (fresh from our SMD assembly): works ok, single 1.8V input power !! Artix A100T, 100mA not bad..
2) testing new build of an Zynq SoM with new Zynq 7045, also success, this pretty fat thing already
3) testing FRESH new build (fresh from our SMD assembly): Mini ITX base for Zynq UltraScale+ MPSoC, also most things work, PCIe, USB3, DisplayPort are OK

guess its enough for today, time to round up, mpsoc SATA tests will do tomorrow..

[westfw]

I think a lot of you are missing the point.
The original poster is already using an FPGA with an embedded soft core (Z80.)
His question is that given that you already has both FPGA and z80core available, how do you decide which things you're going to use FPGA resources on, rather than implementing wholly them in software on the core.  It's a tough question - I've observed that the most elegant solutions frequently involve using a bit of both (ie providing a very wide shift register to help generate video...)

[uncle_bob]

I think a lot of you are missing the point.
The original poster is already using an FPGA with an embedded soft core (Z80.)
His question is that given that you already has both FPGA and z80core available, how do you decide which things you're going to use FPGA resources on, rather than implementing wholly them in software on the core.  It's a tough question - I've observed that the most elegant solutions frequently involve using a bit of both (ie providing a very wide shift register to help generate video...)

Hi

Well, this is where some *input* from the OP might be useful. It's amazing how many of us manage to put up multiple posts on a topic like this over a few days. In the same period the person who was desperate for the information is MIA.

As long as you have not run out of resources, trading off resources isn't much of an issue. As you add code to your core, you likely run out of memory to store that code. You now have an external flash to interface to and the cost of the chip. That *might* also provide init data to the FPGA. In a *lot* of cases you have a serial flash for init and your core uses parallel flash for speed. It's still a cost and pins used. Once you hit that point (added silicon) you are at the point that a 50 cent MCU is worth looking at.

Bob

[alank2]

westfw is right, this is what my original question was.  uncle_bob I'm not MIA as much as I haven't had anything to ask/add - if others have a different direction they want to take the thread I don't mind.

[nctnico]

So having played with an FPGA for about a week now and making some changes to a SD controller so it will work with SDHC cards as well as SD cards.  I was actually modifying it based on Chan's FATFS SD initialization example.  This change increased the size of the sd module considerably to where it barely fits the FPGA now.

Today while driving around it occurred to me that this logic, initializing the SD/SDHC could be moved to the bios instead (which is running on a Z80 in the FPGA).  If the FPGA interface just allowed for controlling the SS line on the SD Card and provided a way to send a byte and receive a byte, then it could be much less complicated than the way it is implemented now which is more like disk devices were implemented at the time (3 register bits, 8 data lines, a n_RD and n_WT signal).  So, the FPGA could handle what it needs to (SPI) and the bios could handle what it needs to (card detection, sd/sdhc, lba calculations, etc.).  The bios would be a bit bigger, but the fpga resources would be considerably less.

My question is, where does it make sense to implement something in fpga logic vs. microcontroller/processor code.  Are there any schools of thought or best practice ideas on this?

Usually sequential stuff works best from a softcore. In the past I have used the Picoblaze in several FPGA designs because it was quicker to write a small piece of software than to design a complicated piece of logic. In a recent project I'm using a 32 bit softcore. In the first version I used software to do certain operations because it was fast enough. A later version needed more channels so I moved a lot of logic to the FPGA side to make it faster. The advantage was that I already had a working example so it was only a matter of translating the operations into VHDL instead of designing from scratch.