I don't mean a separate chip. All I want to say is that you don't
want your MCU to be reconfigurable. It should be as standard as
possible for many reasons. The most important of them is that
a standard CPU has mature and debugged toolchain. The next one is
that my personal memory is too precious a resource to remember
the peculiarities of niche architectures, e.g. NIOS. What is NIOS?
A variant of an ARM core? Or a PowerPC? Or perhaps a brand name
of one of the MIPSes? No, it turns out not to be the case. Then,
my dear FPGA vendor, please go and...
I will grant you that the tools may be better for a mainstream
instruction set, but otherwise I don't see the advantage. I don't see
how your personal memory has much to do with it. Most programmers use
the tools, meaning HHL compilers. The main point of using an HLL is to
*not* need to know anything about the instruction set. If you can't
write HLL code for the specific CPU involved, then you have other issues.
I don't insist the "standard" word should mean ARM, however it would
be good. The Virtex family used to have up to 4 PowerPC cores, which
is fine. The problem is that a soft core eats my reconfigurable
resources which artificially boosts the cost of the FPGA chip, because
I need one or two grades bigger chip than is really necessary with
a hard core. And the el cheapo lines do not have them -- a Spartan
is what I would ever need, I am not crazy enough to buy a Virtex or
Startix for advanced amateur designs. No to mention that most of them
come in BGA which is a big no-go for many reasons.
You are creating a straw man argument. I can fit a soft core CPU into
nearly any FPGA you hand me. Lattice is making some very tiny ones
without memory blocks, but otherwise soft cores are not so large. In
fact, it may have been this thread where someone pointed out that the
NIOS2, a 32 bit processor, can fit in fewer than 600 LUTs! That is
small enough to allow multiple CPUs in most FPGAs with tons of room left
over for peripherals and custom logic.
In my case it's PCB routing complexity. I am not going
to use 4+ layers of copper just to satisfy the monster's
signal integrity requirements. 2 layers is all I can have.
Uh, what monster???
Exactly. But then you use 60% of the chip's reconfigurable
capacity and most of the BRAMs just to embed an MCU? Makes
no sense to me. The need for a hard macrocell providing
a decent 32-bitter is so obvious...
I won't argue that having a hard CPU on an FPGA isn't a nice thing. But
it is not such a bad thing to use a soft core CPU. 60% of the
*smallest* FPGA with block RAM I have seen is enough to embed a 32 bit
soft CPU. In fact, I had to do a bitware upgrade to an existing design
and was worried about not having enough room for the logic. My fall
back plan was to remove the slow functions from the logic and use a soft
CPU because it would be so compact in comparison.
As I said, I need ~40 PWM channels, 4 CANs and/or 6 RS485 + Ethernet.
Impossible on an MCU, so an FPGA (probably a Spartan 6 in TQFP144)
is the most promising candidate. But the rest is so much CPUish...
I'm not sure that is impossible on an MCU. Maybe it is impossible on an
MCU you can buy, but a custom design might do nicely. Just saying 40
PWM channels doesn't tell me how much CPU cycles are needed. But since
you can have so many CPUs on even a smallish FPGA, I expect you could
divide and conquer quite easily. Or you can use dedicated logic and a
soft core for the Ethernet and any other functions that are better suited.
Taken literally -- surely. But often you don't know all
the requirements or just didn't have the right idea at
the time of initial design. If you have spare FPGA resources,
you can use them to extend the device abilities.
You can wave the same hands for CPU cycles. The only difference is MCU
I/Os are not as flexible, typically being constrained to one set of pins
or a small selection of I/Os. I guess that was your point?
Mort of my signals is so slow that the signal integrity issues
rarely matter.
I'm not talking about SI, I'm talking about the large (by comparison)
delays in I/O routing to the clock net. The clock inputs have a direct
connection which allow deterministic timing for I/O setup and hold
times. If your designs are so slow that isn't an issue, fine, but that
is not very common.
I mean you don't need to design your own PCIe controller.
Or a DDRx controller. Or Ethernet. Or CANBUS. Name your
own typical interface. It's a waste of resources (and power)
to implement them using the reconfigurable fabric. You
would like to have a hardware core + be able to add your
own when you need something fancy. Some of these have
already been "hardened", e.g. the multipliers (all
post-Cyclone era FPGAs) or the DDR controller (in Spartan 6).
An MCU, please?
Ok, I agree. I think that is the direction FPGAs will be headed, but
not very fast. FPGA makers see their market as the deep pockets of the
data/telecoms providers pumping out many, many boxes that keep our
communications running at warp speed (lol). So far those markets have
been served well by the same model, bigger, faster, very expensive FPGAs
pushing the limits of silicon processing just like the mainstream GP
CPUs. But just like GP CPUs, I see the market changing over the next 5
or 10 years. I think FPGAs will need to incorporate CPU cores, but not
exactly like embedding an MCU, possibly more like making a small CPU a
functional block like a LUT.
Check out the GA144 from greenarrays.com. They don't market their chip
this way, but I see it as a Field Programmable Processor Array (FPPA) to
be used in a similar manner to an FPGA. These CPUs can't be used like
conventional CPUs. The memory is too small and the CPUs are only
connected to adjacent CPUs. But if you can master the concept, I think
it can be powerful.
It was just an example, my favourite architecture.
Any standard core would be fine.
The toolchain is mature.
How mature do you need?
No, there is no need to be "portable" when there is no
real reasons for that.
In the digital part? 3.3V is enough for me. Most of the
ARMs (from the ball park I care about) need 1.8V, but are
kind enough to produce it themselves with a built-in LDO.
You can override it with a switcher if you care about
efficiency. No Cyclone/Spartan is equally kind.
Then don't use a Cyclone/Spartan part...
The current one: 12V rectified AC for the power part,
~8V DC (for the remote boards to compensate the wire resistance
and to feed the gates of power MOSFETs), 5V (for CAN), 4.4V for
the GSM module and 3.3V for the rest. I can get rid of the
5V rail if I buy the 3.3V TI CAN PHYs.
So you have some five power rails? Sounds to me like adding a 1.x
supply would be no big deal. I included a tiny 1.2 volt switcher on my
last design so I could use either version of the FPGA, the one with the
internal LDO or the one without.
The time between the act of pressing "build" and getting the resulting
bitstream in Quartus. Don't care what the tool does there.
I know you don't care, but what takes so long? My compiles only take a
few minutes.
I mostly use AVRs and ARMs.
Touche!
Sounds very interesting, will have a look. What can I have for, say,
$50? Something comparable to Spartan 3S200 would be enough...
And where can I buy them at the tremendous amount of 1 piece?
Try Digikey, I believe they sell Microsemi. I know I have checked
prices and if I didn't get it from Digikey I don't know where I did.
The ballpark price for the Smart Fusion is under $50 I believe, but not
by a lot. The packages may not make you happy though. They seem to
think the Smart Fusion chips need a bazillion I/Os. I have no idea what
market they are pursuing. I guess they are trying to keep the ASP high.
The CPU is an ARM CM3 which should make you happy,,,
