On 14/01/2021 01:05, Theo wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> A lot of the available devices are, as Theo says, too limited. PSoC's
>> have some programmable logic - but its far too limit. It's one thing to
>> say that the logic makes the device flexible - it can be used for an
>> SPI, an I²C, a UART, a PWM timer. But competing devices with boring old
>> fixed peripherals already have an SPI /and/ I²C /and/ UARTs /and/ PWMs.
>> You don't want programmable logic for these things that are commonly
>> found as fixed peripherals - you want the logic for odd things.
>
> Those hard cores are probably lower power too - if you don't use them they
> get turned off. FPGA logic is not known for being super low power.
Yes. I think I mentioned low power somewhere (but not clock gating).
And the MCU manufacturers already have the modules - the hard macros for
die (and these are /tiny/ - therefore virtually free - compared to an
FPGA implementation), the documentation, the header files, the driver code.
>
>>> How many FPGA I/Os
>>> will require pins? I don't agree with mixing the FPGA I/O pins with
>>> the MCU peripherals since the FPGA I/Os naturally mux within
>>> themselves.
>>
>> Here I disagree. Mixing FPGA and MCU pins is exactly what I would want.
>> You'd be free from the usual MCU limitation of having lots of hardware
>> peripherals but not the right pin mux choices to let you have exactly
>> the combination you want. And you'd be free to take advantage of
>> combinations, without having to route signals back on the outside of the
>> device (say you want to use an internal UART but with the data used to
>> modulate a carrier signal). You want this kind of routing to be done
>> internally, not via the pin drivers.
>
> By all means implement the MCU pin mux using FPGA routing if you want.
> That's an argument for the hard MCU to live inside the sea of FPGA, but I'd
> argue it shouldn't be far from the shore. The default configuration might
> have the MCU wired to some sensible pins, rather than everything floating
> unless connected.
I'd definitely want /some/ MCU pins to be direct - at the very least,
you want everything involved in booting and debugging (including at
least one debug UART) and QSPI for reading in your FPGA image.
Perhaps it would be better to think of internal FPGA input/output
connections as just another option in the multiplexer choices for the
MCU peripherals and pins. For a given pin, it might have a multiplexer
letting you select GPIO, UART, or SPI - just add FPGA to that list.
Similarly, a UART might be able to take its input from pin 10 or pin 25
- just add an FPGA signal to the list.
>
>> Certainly I'd want the MCU to be able to control loading the FPGA image.
>>
>> Modern high-end MCUs are now often without flash. You don't want flash
>> on the same die as the MCU - the optimal production processes for flash
>> and high-speed logic are too different, and you end up limiting both the
>> MCU and the flash. Look at the NXP RT10xx series - you have a 600 MHz
>> Cortex-M7 cpu, with plenty of ram, but no flash. One of these, combined
>> with an external QSPI flash chip, is cheaper than a typical 120 MHz M4
>> microcontroller with a fraction of the flash, and the QSPI flash runs
>> faster than on-die MCU flash. (There are some RT10xx devices which
>> include flash - it is a separate die, in the same package, which is nice.)
>>
>> So external QSPI flash (or external die, internal package) is the way to
>> go IMHO.
>
> It depends where your focus is - my interest is in smaller, PSoC scale,
> parts (QFN48 sort of thing). You save die area and board complexity with
> integral flash - yes your parts are slower, but sometimes you don't care
> about that. For those you might want a flash FPGA, to avoid having to copy
> configuration as part of a (slow) boot process.
>
Perhaps. But there are no fundamental reasons why you couldn't do as I
suggested and put the flash on a separate die, mounted internally in the
same package. Even in a QFN48 there is a big difference between the
package size and the die size of the chip - there's room for adding
another small die. And vertical stacking inside the package is also
possible.
Multi-die packaging, whether it is side-by-side or vertical stacking,
used to be /very/ expensive. But it is becoming a lot more common in a
range of devices. I don't think it will be long before we see not just
flash dies but also ram dies of some kind inside high-end MCU (and FPGA)
packages. The big issue with multi-die is power, but that's not going
to be a problem in the sort of things we are envisioning here.
Look at the NXP RT1024 to see the concept:
<https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-mcus/i-mx-rt1024-crossover-mcu-with-arm-cortex-m7-core:i.MX-RT1024>
Although the description says "4 MB on-chip flash", it is /not/ on the
chip - the die. But it is in the same package. Logically, and in the
MCU setup, the flash is an externally connected peripheral.
(If anyone has used National Semiconductor COP8 microcontrollers, this
was also how they implemented their OTP devices.)
>>
>>> Many
>>> years ago Xilinx was working on partial reconfiguration in a way that
>>> would allow sections of the chip to be independently designed and
>>> configured. I think they never got it ready for prime time and only
>>> really ever saw it in a small number of high volume designs with lots
>>> of customer hand holding by the Xilinx experts.
>>
>> I remember hearing about that kind of thing (Altera had something of
>> that sort too, I think?). Wasn't it only available on their paid-for
>> subscription versions of their tools? Keeping a technology out of the
>> hands of amateurs, learners, experimenters and small users is a
>> sure-fire way to make sure no one uses it.
>>
>> (Even though I haven't used programmable logic much for a long time, I
>> still try to keep up with what's happening in the FPGA world.)
>
> It's actually commonly used these days. A lot of that is for accelerator
> cards in servers: you program the periphery of the FPGA with the I/Os (PCIe,
> DDR4, ethernet, etc) and then you can swap in different blocks in the middle
> for different applications. AWS F1 does this.
>
> Another application relevant to this thread is that the newer Intel parts
> (Arria 10, Stratix 10) which have an ARM core in the middle use partial
> reconfiguration as part of the boot process. To bring up the ARM, you need
> to provide it with some RAM. So first of all you configure enough of the
> I/Os to allow the ARM to get at its DDR4 channels. Then you can boot Linux.
> Later on you can program up the rest of the FPGA with whatever logic you
> want to run on it. Linux provides an API where you can funnel bitfiles at
> the FPGA logic, with associated device tree parts to teach Linux about what
> hardware it should expect inside.
>
The devices I have been thinking about would be a bit smaller - not big
Linux systems. But I guess technology often starts at the high-end,
high profit devices and rolls down to the mass market.
>>> That's actually how
>>> Cypress got started with their PSOC devices. They didn't have the
>>> fancy software working very well, so they had weekly design seminars
>>> which were really just conference calls for you to pick the brains of
>>> the experts. Great way to get started with the parts, but still not
>>> great in place of workable tools. I believe they have much better
>>> tools now. I helped someone port a Forth to one of the PSOC ARM
>>> devices that actually was not programmable in a real sense, it has
>>> very flexible serial controllers so the same hardware could do SPI,
>>> UART or I2C if I recall. I figured out how to install a UART so the
>>> Forth could boot up and give a command prompt. Funny actually. The
>>> one small family of non-programmable PSOC devices.
>
> The PSoCs are interesting in that they have some kind of firmware inside.
> Different part numbers have different firmware that enable or disable
> different features. Of course somebody hacked the firmware to enable
> the features...
> https://hackaday.com/2017/03/04/reading-the-unreadable-srom-inside-the-psoc4/
>
I'll read that link when I get the chance, thanks.