Free ARM core for FPGA

[asmi]

Why would you trade FPGA for a dozen of ARM cores?

I don't have to trade anything - I can have both, and with Zynq you can't

[langwadt]

huh? they are two totally different classes of cpus, if all you need is a small state machine programmable in C or assembly
M0 fits the bill, if you need processsing power and linux A9 fits

If all you need is a small state machine, it's best programmed directly in HDL.

No. The turn-around time on a large FPGA design can be several hours compared to several seconds to recompile software. Sure you can do simulations but if you have real hardware 'in the loop' then that goes out of the window. No, I'm not talking external chips here but complicated external systems. Using software to solve a complicated problem is much quicker. One of the FPGA projects I'm responsible for takes at least 2 hours to build in a minimal setup. This has a softcore it is a lot quicker to change when doing algorithm & parameter tweaking.

and you can do in on the fly

[langwadt]

Why would you trade FPGA for a dozen of ARM cores?

I don't have to trade anything - I can have both, and with Zynq you can't

sure you can if it fits in the PL and with a bit of trickery you could even run code from the A9 memory

[NorthGuy]

... what kind of applications it excels at where other techniques like DSP blocks or sprawling logic/LUTs don't work as well, are difficult to get to work right, or are grossly resource inefficient.

First of all I would rule out data processing. Say, you have a core running at 200 MHz and producing some work at the loop. I guess, such loop will be at least 20 cycles (especially with ARM architecture), which means loops are coming at 10 MHz. Let's say, you can do the same task in fabric at 300 MHz. How do you replicate such performance with cores? Install 30 cores and distribute the processing? It may end up to be much bigger job than doing it with FSM in fabric. But may be you're content with 10 MHz? Why would I need FPGA in the first place?

Housekeeping tasks? You certainly can do them with ARM core. Or without an ARM core. May be it's just me, but I don't care much how the housekeeping is done. Creating a counter in HDL is about as easy as in C.

IMHO, soft cores might be used for complex UI, complicated command interfaces, long slow and diverse calculations. The more complex and diverse is the task, the more useful is the core, because it saves lots of fabric. But also, the more complex tasks will require more memory. You have a choice of really small cores, such as Picoblaze, where you can add custom commands to the stock core and make things working nicely and efficiently. Or, you can design your own cores which have a limited set of operations (exactly what you need). Another choice is a big core, such as ARM or Microblaze. If you seriously need it, I think Zynq is much better choice, because it is implemented in hardware, runs much faster, has autonomous memory. You put the PS into the center and use PL as a slave which does all the fast processing tasks and is controlled by the CPU. It's easy to develop your apps in PS, easy to re-compile and re-run (without even touching PL), and you have plenty of resources to spare. Such approach will save you tons of time, effort, and will produce an efficient system.

I think there's some overlap between using Picoblaze/specialized cores and going Zynq. Soft ARM cores (or Microblaze for that matter) hardly can fit in between. Even if you want to get an ARM core because you're an ARM fan, Zynq is still ARM, so you've got to love it.

[langwadt]

... what kind of applications it excels at where other techniques like DSP blocks or sprawling logic/LUTs don't work as well, are difficult to get to work right, or are grossly resource inefficient.

First of all I would rule out data processing. Say, you have a core running at 200 MHz and producing some work at the loop. I guess, such loop will be at least 20 cycles (especially with ARM architecture), which means loops are coming at 10 MHz. Let's say, you can do the same task in fabric at 300 MHz. How do you replicate such performance with cores? Install 30 cores and distribute the processing? It may end up to be much bigger job than doing it with FSM in fabric. But may be you're content with 10 MHz? Why would I need FPGA in the first place?

Housekeeping tasks? You certainly can do them with ARM core. Or without an ARM core. May be it's just me, but I don't care much how the housekeeping is done. Creating a counter in HDL is about as easy as in C.

IMHO, soft cores might be used for complex UI, complicated command interfaces, long slow and diverse calculations. The more complex and diverse is the task, the more useful is the core, because it saves lots of fabric. But also, the more complex tasks will require more memory. You have a choice of really small cores, such as Picoblaze, where you can add custom commands to the stock core and make things working nicely and efficiently. Or, you can design your own cores which have a limited set of operations (exactly what you need). Another choice is a big core, such as ARM or Microblaze. If you seriously need it, I think Zynq is much better choice, because it is implemented in hardware, runs much faster, has autonomous memory. You put the PS into the center and use PL as a slave which does all the fast processing tasks and is controlled by the CPU. It's easy to develop your apps in PS, easy to re-compile and re-run (without even touching PL), and you have plenty of resources to spare. Such approach will save you tons of time, effort, and will produce an efficient system.

I think there's some overlap between using Picoblaze/specialized cores and going Zynq. Soft ARM cores (or Microblaze for that matter) hardly can fit in between. Even if you want to get an ARM core because you're an ARM fan, Zynq is still ARM, so you've got to love it.

if you do FSM in fabric it could take hours to make a change with code it takes minutes and designing your own core means making you own tools

[NorthGuy]

if you do FSM in fabric it could take hours to make a change with code it takes minutes and designing your own core means making you own tools

Who cares if your core only gives you 10% of the design speed. It's like bringing a bicycle to a drag race and say: "look guys, it took me only 2 minutes to prepare my bicycle for the race!"

It doesn't take hours to make a change to HDL. You usually break it into parts and do piece by piece. Even when you need to compile a big project, it's not the end of the world. Although compile times are long (and I hate that), you figure out things to do while it is synthesising/optimizing/implementing ...

[brucehoult]

Why would you want this instead of a picoRV2?

That's "PicoRV32". Or one of the other freely available RISC-V cores. Yes, good question.

PicoRV32 needs on average about 4 clock cycles per instruction. But it runs at 400+ MHz on Xilinx 7-series, so it's 100+ MIPS. I don't think a soft M1 is going to be allowed to run that fast (an SoC M0+ is 50 MHz max, I suspect contractually).

PicoRV32 can be configured to use as few as 810 LUTs, default about 1000, and all the bells and whistles (PCPI, IRQ, MUL, DIV, BARREL_SHIFTER, and COMPRESSED_ISA features) 2100.

If you're writing in C then you're probably not going to notice a lot of difference. And if you don't need hardware multiply and divide or fast arbitrary shifts or super-compact code then you can save a lot of LUTs with PicoRV32. And you can mix and match exactly which of those *is* important to you.

[asmi]

PicoRV32 needs on average about 4 clock cycles per instruction. But it runs at 400+ MHz on Xilinx 7-series, so it's 100+ MIPS. I don't think a soft M1 is going to be allowed to run that fast (an SoC M0+ is 50 MHz max, I suspect contractually).

Example design for Arty-A7 has M1 core running at 100 MHz. And I kinda suspect it could be pushed farther if desired.

[langwadt]

if you do FSM in fabric it could take hours to make a change with code it takes minutes and designing your own core means making you own tools

Who cares if your core only gives you 10% of the design speed. It's like bringing a bicycle to a drag race and say: "look guys, it took me only 2 minutes to prepare my bicycle for the race!"

not everything is a dragrace

It doesn't take hours to make a change to HDL. You usually break it into parts and do piece by piece. Even when you need to compile a big project, it's not the end of the world. Although compile times are long (and I hate that), you figure out things to do while it is synthesising/optimizing/implementing ...

doesn't matter why it takes long, the result is the same; it takes long much longer than software

[mac.6]

Everything in electronic/embedded is a dragrace. Not faster product but faster time to market...

[langwadt]

Everything in electronic/embedded is a dragrace. Not faster product but faster time to market...

and if it takes 20 minutes to get the dragcar ready to run the bike will be first across the line

[NorthGuy]

and if it takes 20 minutes to get the dragcar ready to run the bike will be first across the line

and then it takes only a little bit of marketing touch to convince people that the bicycle is in fact the best dragster.

The force has a strong influence on a weak mind

[langwadt]

and if it takes 20 minutes to get the dragcar ready to run the bike will be first across the line

and then it takes only a little bit of marketing touch to convince people that the bicycle is in fact the best dragster.

The force has a strong influence on a weak mind

who is convinced that "the bicycle is in fact the best dragster" ?

[Doctorandus_P]

Gosh it's "free" for Xilinx stuff. (Yawn).

Anyone here familiar with opencores?
https://opencores.org/
100+ different uC cores from different architectures (in variable state of maintenance). and lots of other stuff.

[nctnico]

Gosh it's "free" for Xilinx stuff. (Yawn).

Anyone here familiar with opencores?
https://opencores.org/
100+ different uC cores from different architectures (in variable state of maintenance). and lots of other stuff.

If you ever used something from Opencores then you'll be cured quickly. 99.9% of it is pure rubbish.

[legacy]

If you ever used something from Opencores then you'll be cured quickly. 99.9% of it is pure rubbish.

I agree.

[a59d1]

If you ever used something from Opencores then you'll be cured quickly. 99.9% of it is pure rubbish.

I agree.

I don't see anything wrong with the NEO430. https://opencores.org/websvn/filedetails?repname=neo430&path=%2Fneo430%2Ftrunk%2Frtl%2Fcore%2Fneo430_cpu.vhd

[technix]

AFAIK Xilinx FPGA contains hard DDR memory controllers and there is a reference implementation for a XIP-capable QSPI master. If you need a Cortex-M0+ with tons of RAM and Flash (e.g. 1GB RAM + 128MB Flash) this might be the only option available: Cortex-M0+ and two QSPI controller in the FPGA fabric, make use of that hard DRAM controller, two MT41K256M16 DDR3 chips on the DRAM controller, and two W25Q256 QSPI chips on the two QSPI controllers. (With more RAM than Flash, it is a better idea to link application code to run from DDR3, store it hard compressed in QSPI, and expand them into DDR3 in the bootloader.)

[asmi]

M3 core is now available too. Didn't try it myself yet.

[SiliconWizard]

Is ARM mandatory?
You could try the Potato processor: https://github.com/skordal/potato