As long as the softcore is just a supplement to the really complex
logic. Otherwise it is not the best way to use the FPGA resources
in order to emulate an ARM. There already are dirt-cheap ARMs on
the market.
The issue is not the cost of an MCU. There are any number of reasons
why not to use a separate chip for the CPU. The one I encounter most
often is board space. In a design I did some years ago I barely had
room for the logic at all, but there was no way I would have been able
to squeeze in a separate MCU package. There is also the cost. Although
a $3 CPU seems cheap, if it can't do the entire job, you can likely
include a soft CPU on the FPGA and only have one part rather than two.
If an MCU does the entire job you need, then fine, use it. But there
are plenty of times you need both and you can always include a CPU on
your FPGA, but it is hard to make a CPU do what the FPGA does.
I've done just a single hobby project based on FPGA
(and think about the next one), but it works and my experience is
as follows. Pros:
1. You can solder the chip and *then* start thinking what
actually it should do.
That's not a good idea for either an MCU or an FPGA.
2. The PCB routing in case of not very demanding signals
is so easy...
There are plenty of dedicated I/Os on an FPGA. Clock lines are the most
obvious. Although you can bring a clock into the chip on any I/O pin,
if you don't use a clock pin it will have extra delay getting to the
clocked elements. This can cause timing issues on clocked I/Os.
3. There is no problem with resource conflicts. When I want
an ARM with 6 UARTS, there are not many of them and then...
look... I can't use CAN becase it reuses the pins of one
of the UARTs... remap... damn, now the Ethernet MII bus
collides with that. On an FPGA I can have 134 UARTS if
I want and no pin collisions.
The routing on an FPGA is one of it's claims to fame. It is also the
major source of the "inefficiency" and extra cost compared to dedicated
logic. But most of the time the "cost" of using an FPGA is mitigated by
Moore's law and the result of FPGAs often using newer and more efficient
fabrication processes.
4. There is simply no competition for FPGAs when precise
timing is required. It is just so indecently easy. Doing
something as "complex" as 40 PWM channels (which is what
I need now) on an MCU is a nightmare.
Yeah, I looked at using a 144 core MCU to control an SDRAM. Although
each MCU could run at up to 700 MIPS, the timing was not specified well
enough to big bang the I/Os for the SDRAM at any speed above some 25 MHz
(ball park).
Cons:
1. You can simulate basically anything, but most of the
time there is no need for that. Some functional blocks
have the only sacred specification and you better not
"improve" them. Memory controllers, serial protocol
controllers, the CPU.
I'm not sure what this means.
2. Why on Earth is there something as bizarre as NIOS
or *blaze? We don't need the next invention of a wheel.
The world pretty much converged to the ARM architecture,
so I do not want to waste my time on learning about
a niche design just because it is the only thing I can
have there because it doesn't exceed the resources
available (opencores) or because of legal issues. I do
want an ARM in every Spartan-class FPGA. I am not going
to buy a Virtex just for that purpose.
It is not possible to implement an ARM on an FPGA without paying huge
license fees. But no matter, what is magical about an ARM? No
instruction set owns the market. ARM has no real advantage over other
CPUs in an engineering sense. There is little utility to sticking with
one instruction set unless you program in assembly language. However,
if you have a large code base that is not easy to port to a different
processor, then stick with what you know.
3. No analog stuff. Everything interesting needs to
be external. Welcome back to the 80s... :-/
I suggest you look at the Microsemi Fusion and Smart Fusion devices.
Fusion means it has analog on chip and Smart Fusion means it has analog
plus an ARM CPU. I have not worked with it, so I don't know much about
it. It is also a bit pricey for the original conversation we had in
this thread.
4. Supply voltage issues. Do we really need 3 of them?
I don't know, do you? My current board has four power supply voltages
and an extra 3.3 volt on board for the CODEC (a total of 5 separate
rails) , but only one is for the FPGA. How about your designs?
5. Why does it take so long to recompile the design?
How long is a piece of string? What?
Are you talking about the place and route time? That depends on the
size of the chip and the speed of your processor (and amount of memory).
I tend to use smaller designs which compile fairly fast. But more
importantly that is not a real issue because I don't compile until the
design passes simulation and finding bugs usually takes a while longer
than the compile.
6. Using a ready-made MCU at least the core has been debugged.
Do I really need to debug the processor in addition to debugging
its program?
I don't know, do you? Which processor are you thinking of using? What
is the application? What are your requirements? BTW, have you read the
errata sheet for any MCU? They are typically very long with lots of
bugs they don't plan to fix. Pick a new member of the family and you
get to find the bugs!