Cortex-M hardcore in FPGA?

[stmdude]

After recently experiencing a few disappointments with the STM32 range of MCUs, I've been looking for alternatives.

In addition to the regular MCUs, I've been thinking of the benefits of having a Hard-core CPU combined with FPGA fabric, so I can synthesize my own peripherals, but I haven't been able to find a reasonable chip.

The Zyncs are overkill in price, performance and complexity, but the idea is exactly what I'm looking for.

I'm looking for something much simpler, like a cortex M-series core and 4-8K logic cells, and preferably available in a decently solderable package.

The only candidate I've found is MicroSemi, but their website doesn't exactly instill confidence in me (severely lacking actual information).
There has to be others out there, but my google-foo is failing me.

Anyone here know of some other alternatives, or even better, have experience with a chip like this?

[brucehoult]

* brucehoult braces for the avalanche of PSoC people...

https://en.wikipedia.org/wiki/PSoC

[ataradov]

* brucehoult braces for the avalanche of PSoC people...

Yeah, take your poor experience with MCUs, and make it just a notch worse

Also, may be if you could tell us what exactly went wrong, we could suggest a replacement MCU.

[stmdude]

Also, may be if you could tell us what exactly went wrong, we could suggest a replacement MCU.

Well, the most recent disappointment was with the STM32F446, which has a different USB controller than the other chips in the F4xx series. Something that isn't highlighted or mentioned in the migration documents.
The USB Drivers ( http://www.st.com/en/embedded-software/stsw-stm32046.html ) says that they support the F446 in the latest version, but it only supports the FS USB block, and it only works if you only transmit/receive a few packets per second. Any faster and it falls apart..

Another issue thats been brewing for a few years is that ST is moving over to their HAL, which, honestly, is a pile. New chips aren't supported by the old StdPeriph libraries.

Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.

The Cypress PSoCs seem interesting, but being forced into Windows is a showstopper for me.
 

[nctnico]

Also, may be if you could tell us what exactly went wrong, we could suggest a replacement MCU.

Well, the most recent disappointment was with the STM32F446, which has a different USB controller than the other chips in the F4xx series. Something that isn't highlighted or mentioned in the migration documents.

That is the biggest problem with ST's ARM lineup and one of the main the reasons I use NXP's ARM controllers. NXP's ARM controllers have the same (or at least very similar) pheripheral through their entire range so you can switch between various controllers more easely. Because of that it is rare I use the same NXP controller in different projects.

[legacy]

I don't really want to write a USB stack for example.

[langwadt]

Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.

so instead of writing drivers you want to  write drivers and peripherals?

[stmdude]

Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.

so instead of writing drivers you want to  write drivers and peripherals?

   Sometimes, it would make sense to write your own peripherals. For example, in one of my projects, I'm bitbanging SWD. That would be a perfect peripheral to synthesize. But, yea, I probably wouldn't want to synthesize _every_ peripheral.

[stmdude]

I don't really want to write a USB stack for example.

??  What would you recommend doing if you need USB connectivity, and you have two stacks to choose from. The first one doesn't work beyond a few packets/second, and the second one doesn't support the functionality you need, nor is it even close to production quality?

[ataradov]

Well, the most recent disappointment was with the STM32F446, which has a different USB controller than the other chips in the F4xx series. Something that isn't highlighted or mentioned in the migration documents.

But your USB FS/HS controller in FPGA will probably take 2-4K gates alone, plus external PHY. USB is the worst reason to want FPGA + Hardcore CPU.

Plus you need to make one that works. There are a few things here and there, but not really a coherent stack that I could find.

Another issue thats been brewing for a few years is that ST is moving over to their HAL, which, honestly, is a pile. New chips aren't supported by the old StdPeriph libraries.

That is true for all vendors. Relying on vendor software support is a big mistake. Build your own software library.

Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.

You would have to for your own peripheral anyway. And it is not that hard to write a USB stack for simple scenarios.

Also, the biggest problem for USB in FPGA is memory. Small FPGAs don't have enough of embedded memory, and you need to have buffers for USB.

[nctnico]

Another issue thats been brewing for a few years is that ST is moving over to their HAL, which, honestly, is a pile. New chips aren't supported by the old StdPeriph libraries.

That is true for all vendors. Relying on vendor software support is a big mistake. Build your own software library.

That only works for simple peripherals. For things like USB and TCP/IP you need to get a third party stack because it is way too time consuming to write and test your own.

Sure, I could just write my own drivers, but only to a certain extent. I don't really want to write a USB stack for example.

You would have to for your own peripheral anyway. And it is not that hard to write a USB stack for simple scenarios.
Also, the biggest problem for USB in FPGA is memory. Small FPGAs don't have enough of embedded memory, and you need to have buffers for USB.

Most microcontrollers have like 2kB of SRAM for the USB interface so I guess that should be enough. Nowadays 2kB is peanuts for a modern FPGA.

[andyturk]

The Cypress PSoCs seem interesting, but being forced into Windows is a showstopper for me.

You don't have to use their IDE for *everything*. It's pretty easy to have it generate a Makefile and roll your own environment elsewhere (e.g., macos).

[MT]

After recently experiencing a few disappointments with the STM32 range of MCUs, I've been looking for alternatives.

A "few"? USB but what "else" is different?
Btw, may i ask on your F446 can you change PB3,PB4 PA15 from ALT to GEN mode without losing debug interface or causing CPU to behave funny?

[jnz]

... Um... Why don't you just move over to the STM32F4 part that has a better USB peripheral? Or am I asking too simple of a question this late in the thread?

[Ice-Tea]

Bit more on-topic: check out Microsemi Smartfusion devices.

[stmdude]

Btw, may i ask on your F446 can you change PB3,PB4 PA15 from ALT to GEN mode without losing debug interface or causing CPU to behave funny?

ALT to "GEN"?  Are you talking about changing the pin from alternate-function to regular GPIO?
There _might_ be some issues with that, as they're shared with the JTAG-DAP, and in other STM32s, thats an issue unless you switch the chip over to SWD only. However, I can't find any register to do that in the 446.

If you give me a bit more info, I can try it out.

[stmdude]

... Um... Why don't you just move over to the STM32F4 part that has a better USB peripheral? Or am I asking too simple of a question this late in the thread?

That's what I'm doing for this project. I'm moving to a F429 instead. Twice the cost, with no additional functionality that I need/want.
I'm looking into the FPGA stuff as a way to be able to spin some custom peripherals to offload the CPU when I need to talk to weird and wonderful peripherals.

After recently experiencing a few disappointments with the STM32 range of MCUs, I've been looking for alternatives.

A "few"? USB but what "else" is different?

On the F446, not a lot (except the USB stuff I've discovered). The disappointments are more with the whole family of MCUs. The newer chips aren't supported with the tried-and-tested StdPeriph library (yes, I can bang the registers myself, but sometimes you just want to get the easy stuff done, quickly).
Also, their prices are pretty insane. I'm switching from the F446 to F429, which is a $12 chip (@1 qty). I can source dual-core Cortex-A9 SoCs for $2...
Heck, I'm seriously considering using Nordic Semi nRF chips instead of the STMs in a few projects. No need for RF in the projects, but the chip is cheaper.

Bit more on-topic: check out Microsemi Smartfusion devices.

I've looked at them (as I said in my initial post), but their website is very low on actual information. Maybe I should dig deeper in that particular rabbithole...

[MT]

author=stmdude link=topic=95231.msg1304750#msg1304750 date=1505764611]
On the F446, not a lot (except the USB stuff I've discovered).

There are actually some difference (F446) low power and clock gating but you gain CCMRAM with the 429, ST even managed to do a migration paper.  www.st.com/resource/en/application_note/dm00161778.pdf

The disappointments are more with the whole family of MCUs. The newer chips aren't supported with the tried-and-tested StdPeriph library (yes, I can bang the registers myself, but sometimes you just want to get the easy stuff done, quickly).

I recall STDlib STSW-STM32065 also includes F446 target. I do direct register, cant stand the gobelybockgebrock HAL!
It would have been easy if ST had used definition labels that was understandable, or manuals that make sense.

Also, their prices are pretty insane. I'm switching from the F446 to F429, which is a $12 chip (@1 qty).
I can source dual-core Cortex-A9 SoCs for $2...

Yes, looking at retailers pricing its all over the place, makes no sense at all.

ALT to "GEN"?  Are you talking about changing the pin from alternate-function to regular GPIO?
If you give me a bit more info, I can try it out.

Sent you info in a PM!

[jnz]

That's what I'm doing for this project. I'm moving to a F429 instead. Twice the cost, with no additional functionality that I need/want.
I'm looking into the FPGA stuff as a way to be able to spin some custom peripherals to offload the CPU when I need to talk to weird and wonderful peripherals.

Yea.. OK. The STM32F429 is too expensive, so you're question is about hardcoding an ARM core an FPGA.

Good luck.

[ataradov]

Yes, I don't get the point of this thread. It looks like the amount of manual work is going to increase many times with FPGA path (even if such thing existed and was practical).

Don't like HAL/Cube/wehatever? Well make your own. You will have to anyway with FPGA.

So if you are looking for simplicity, then just pick a micro and build up a code base you know and can reuse.

[Mr. Scram]

The Cypress PSoCs seem interesting, but being forced into Windows is a showstopper for me.

This would have been excellent information to add to the first post. Although I would argue that spinning up a VM and getting on with it could make your life much easier.

* brucehoult braces for the avalanche of PSoC people...

https://en.wikipedia.org/wiki/PSoC

I'm surprised Danadak hasn't chipped in yet

[langwadt]

Also, their prices are pretty insane. I'm switching from the F446 to F429, which is a $12 chip (@1 qty). I can source dual-core Cortex-A9 SoCs for $2...

I wonder how much of that price difference is because of the large flash on the M4's

[JPortici]

I don't understand why you are not seriously considering different families/architectures then.. aside the fact that you'd have to change your username then

but what does the STM32F4 have that you can't find in others so it's so difficult to switch?
I wonder if it's the 2xCAN + USB combo, i recently went for a PIC32MK for this very reason, it was the cheapest (available in a small QFN package)
but of course, i don't think this is the case.

[legacy]

Yes, I don't get the point of this thread. It looks like the amount of manual work is going to increase many times with FPGA path (even if such thing existed and was practical).

Don't like HAL/Cube/wehatever? Well make your own. You will have to anyway with FPGA.

So if you are looking for simplicity, then just pick a micro and build up a code base you know and can reuse.

 

[stmdude]

Yea.. OK. The STM32F429 is too expensive, so you're question is about hardcoding an ARM core an FPGA.

No, not harcoding. A hardcore. And, yes, it's possible to do at a reasonable price-point. Just look at the Cypress PSoCs.

I don't understand why you are not seriously considering different families/architectures then.. aside the fact that you'd have to change your username then

Haha, yea, my username would be an issue.   Not a big one though.
I've shipped >10M devices based on various STM32s, so I have invested a massive amount of time learning the ins and outs of them. I could make a lateral move into he NXP family (for example), but for some reason, I _think_ (I've got no facts backing this up) I'll just swap one set of idiosyncrasies for another.

but what does the STM32F4 have that you can't find in others so it's so difficult to switch?
I wonder if it's the 2xCAN + USB combo, i recently went for a PIC32MK for this very reason, it was the cheapest (available in a small QFN package)
but of course, i don't think this is the case.

What I needed from this particular STM32F4 was:
* HS USB
* 2MB of RAM (I.e, external SDRAM)
* 2 x UART
* 4 x PWM @ >10KHz
* 8 free regular GPIOs

For me, this would be mid-end. No display, and no ethernet or WiFi.

Yes, I don't get the point of this thread. It looks like the amount of manual work is going to increase many times with FPGA path (even if such thing existed and was practical).

No, there would still be regular peripherals on-die. Just like the PSoC. The FPGA fabric should be in addition to what you'd expect from a regular MCU, not instead of.