Over the next two weeks, I am speaking at three conferences (ESC Boston, FPGA Kongress and Embedded Online Spring Conference) on how we can implement Cortex-M1 and Cortex-M3 solutions in our Xilinx FPGAs and SoCs using the Arm DesignStart FPGA program.

If you are not able to attend any of theses sessions, do not worry as in this blog I am going to outline the basics of DesignStart FPGA and how we can get started with it in our devices.

Getting started is very easy, as FPGA developers we will probably already have most of the tools required to create a solution, if not they can be easily downloaded and licensed from either Arm or Xilinx websites.

Vivado (Current examples are based in 2018.2)

Xilinx SDK

Arm Keil MDK — Essential Edition

The fastest way to get started with either the Cortex-M1 or Cortex-M3 is to download one of the reference designs. These reference designs are targeted at Artix-7 and Spartan-7 devices available on the Arty Board, but can easily be port to other boards or your custom board.

But before we jump into the detailed implementation, let’s take a quick look at the Cortex-M1 and Cortex-M3 in a little detail.

Both the Cortex-M1 and Cortex-M3 are 32-bit processors designed for low power, low logic resources and low interrupt latency performance.

The Cortex-M1 is designed very much for constrained applications, which require communication, control and management, while the M3 is intended for a wide range of embedded and IoT applications. To support forward compatibility, the Cortex-M1 implements a subset of the Cortex-M3 instruction set and features.

When it comes to implementing either processor within our device, there are several implementation options which control the configuration — including debug access, breakpoint units, and high-performance interface ports.

Both the Cortex-M1 and Cortex-M3 execute their applications from internal memory. The size of both the instruction and data memory is also configurable when instantiated. Instruction memory can range from 8KB to 1 MB, while data memory can range between 2KB and 1MB.

Communication from the processor to peripherals uses the AXI Lite interface and just like with Zynq / MPSoC and MicroBlaze designs we can connect to several peripherals using AXI Interconnect.

When it comes to the development flow to implement a Cortex-M1 or Cortex-M3 in our FPGA, it is flow which is mostly familiar with. The underlaying hardware design is created in Vivado, which then generates the bit stream, hardware description file (HDF), and crucially as well a MMI file that defines the Block RAM locations used by the instantiated processor in the FPGA.

Using this MMI file allows the application software to be updated as necessary, in the bit stream without the need to recompile the entire FPGA design.

Once we have the HDF file, we can use this to generate a Board Support Package (BSP) within Xilinx SDK. This BSP will contain drivers for all peripherals used within the Vivado design; however, when it comes to application development, we do not use SDK but Arm Keil.

The output from Keil is both ELF and HEX — it is this HEX file which is used with the MMI file and merged into the processor’s instruction and data BRAMS.

When it comes to debugging our application, we can use the Arm DAP link board and its Serial Wire connection or a standalone Serial Wire or JTAG debugger.

If you would like to examine a Cortex-M1 and Cortex-M3 project in more detail, there are two detailed projects on Hackster I recently created:

To wrap up this blog, I am going to answer one question that I am sure will have arisen as you have read and that is: where do Cortex-M1 and Cortex-M3 sit in relation to MicroBlaze?

The answer is straightforward the Cortex-M1 and Cortex-M3 add to our embedded soft-core processor tool box complimenting the existing solutions. The Cortex processors offer a more compact code density, which require fewer block RAMS, and comes with a wide ecosystem of support. While the MicroBlaze provides a higher performance (2–3x over Cortex M) and can provide a Floating-Point Unit (FPU) as well if desired.

The Cortex processors therefore enable an embedded processing software capability which progresses from the Cortex-M1 to the Cortex-M3 and finally the MicroBlaze. As we have already seen the Cortex M1 has forward binary compatibility with the Cortex-M3, while porting a design to MicroBlaze does not require significant effort.

Hopefully by now you understand a little more about using Arm DesignStart FPGA Cortex-M processors within our Xilinx FPGA and SoCs.

If you can make it to one of my sessions, it would be great to meet you. If not, then keep an eye on the blog I will be covering more Design Start examples soon!

See My FPGA / SoC Projects: Adam Taylor on Hackster.io

Get the Code: ATaylorCEngFIET (Adam Taylor)

Access the MicroZed Chronicles Archives with over 290 articles on the Zynq / Zynq MpSoC updated weekly at MicroZed Chronicles.