Rationale

megasoc has been designed to provide a complex SoC component that can 'host' and support the development and evaluation of research components or subsystems. The design allows for seamless transition from FPGA to physical silicon implementation via a pre-verified programmable control system that allows reuse of software and diagnostic functionality to facilitate the configuration, control and diagnostic analysis of research hardware such as custom accelerators or signal processing.

The design is based on an Arm Cortex-A53 CPU core with inspiration from the Corestone 1000 subsystem from Arm. megasoc allows the reuse of the AAA pre-verified IP, documentation and software but it is architected to support simple 'bolting-on' of experimental hardware. The aim of megasoc is to provide a fully Linux capable SoC whilst minimising the cost of physical silicon production.

Technical Overview

megasoc is a complex SoC utilising the Cortex-A53 processor with pad-level support for silicon implementation. Included is:

• CPU - Armv8-a Cortex A53 processor
• Interrupt Controller - GIC 400
• Software Debugger - Arm DAP-lite
• Boot ROM
• XiP QSPI - For program or BIOS
• SRAM
• NIC 400 System Bus
• DRAM controller
• DMA for system support - Off-chip mem to DRAM
• Peripherals (UART, Timers, etc)

Ideally we plan to integrate some high speed off-chip interfaces, but currently we are making a 'Minimal Viable Product' using the IP that has already been obtained. In the future we would like to integrate: 

• PCIe
• Gigabit Ethernet
• USB

For the current implementation please refer to "megaSoC V1 - Architectural Changes" below.

Architecture 

The overall architecture is as shown below. This has been separated into 2 main sections, the CPU and System sections. Development so far has been focused on the CPU subsystem (with the DDR controller implemented on the CPU bus). We are currently exploring options for sourcing the IP for the ethernet, USB and PCIe controllers. 

Address Map

The Cortex A53 has a 40-bit address interface, this gives a total addressable space of 1 TB. For now a simplified 33 bit address map is being created, it is likely that any higher address will be used to expand the DRAM and possibly for direct access from the CPU to the communication interfaces (PCIe, USB, Ethernet) if possible, although these will all likely be controlled by DMA transfers.

Currently this address map is unoptimised (some regions are much larger than necessary, and there are a few empty regions which will likely be filled as development progresses.

CPU Interrupts

The GIC-400 generic interrupt controller supports a maximum of 480 shared interrupts. Currently implemented interrupts sources are shown below, higher interrupts are tied off to 0's

Communication channel

Currently implemented are 4 UART channels. USRT 0 & 1 are connected to the HOSTIO Debug controller, these channels can be used for debug purposes and STDIO. They will require an off-chip HOSTIO controller (currently work on implementing this in a raspberry PI RP2040 chip)

The other 2 UARTs are for general communication and can easily be used with a number of debug connections. Currently the thought will be to use a FT232 chip on the PCB to act as a USB - UART and allow for very simple debug information. 

As described in "megaSoC V1 - Architectural Changes" we have also added a PL011 UART interface. The purpose for this is to act as a fully handshaked UART (CTS, DSR, DCD, RTS, DTR signalling included) which can be used for networking over serial.

Pinlist

Using megaSoC

If you'd like to use megasoc for your custom hardware, you can fork or clone the megasoc project git repository. This SoC reference design is still under development, expand the V1 Tapeout section below for more details.

megaSoC V1 Tapeout

megaSoC V1 - Architectural Changes

Work is currently underway to tapeout megaSoC in 2026. This initial version will be a "Minimal Viable Product" version of megaSoC. This version will not have the complexity of high speed external interfaces and the PCIe, USB and Ethernet subsystems. 

The aim for the initial tapeout of megaSoC is to prove the core compute system, the fabrication flows and provide a good baseline of information to the community on taping out an A-class processor on an advanced technology node. As with the first version of nanoSoC some application scenarios may be limited it will serve as a good foundation for future improvements.

These two controllers will be replaced with an SDIO controller (ZipCPU SDIO) and a UART controller (PL011 from ARM)

Network 

Whilst not ideal, networking is possible over UART. The initial plan for the MVP implementation of this megaSoC-lite version was to use this approach. Network communication is possible using packages like PPP in linux (an example on how to set this up between 2 raspberry pi's). The PL011 from Arm has been chosen as it allows for hardware flow control which is ideal for this application.

We are also looking into using an Ethernet mac subsystem with an RMII interface that would allow for 100 Mbps networking (much faster than over UART). Work is currently being done on integrating this into nanoSoC here. The Ethernet MAC controller and PTP timer have now been instantiated in megaSoC but are not yet verified. 

SD card filesystem 

Ideally a very high speed non-volatile memory would be used for the filesystem using a PCIe interface to integrate an M.2 SSD device. However, it is quite common practice to use SD cards for such applications. The implementation of a PCIe interface and associated PHY for the SD controller is a target for a later version. The ZipCPU project is mostly focused around FPGA implementations. Whilst there is a lot of information available it would require a custom PHY implementation. Without a PHY the system would be limited in the bandwidth achievable for the SD card.

DDR Controller + PHY

For this project, Synopsys have kindly donated their DDR controller and PHY IP to SoClabs. The specific parts used in this project are the uMCTL2 DDR controller and LPDDR4 multiPHY. This will allow for an implementation of megaSoC as a single board computer (SBC), with LPDDR4 module on the PCB. For this initial prototype of the project we are keeping this as simple as possible using a 16 channel LPDDR4 device (most likely something like the D1611PM3BDGVIW-U device from Kingston technology).

For this configuration we are using a 16 Gbit (2GB) device, which we believe will give us a good starting point to ensure enough memory for the OS performance, whilst keeping complexity and cost to a minimum. 

Verification

Behavioural Verification

 

Backend - Hierarchical design Planning

As the megaSoC design is a large SoC, the backend work must be done using a hierarchical/bottom up approach. This means dividing the design into sub-blocks, performing backend on each of those blocks and then bringing the whole design together.

Synopsys Fusion compiler includes a flow for hierarchical design planning that also allows you to break the design into blocks but run the backend in parallel for each of those sub-blocks. This ensures all blocks are in sync at each of the design steps and you can run verification after each point (e.g. post clock opt gate simulations/logical equivalence)

Floorplan

It is a good idea to have an initial floorplan of how the blocks will be split up. Below is our initial estimate for what the floorplan will look like. We expect the A53, DDR, SRAM and QSPI controllers to be the largest IPs that should be worked on hierarchicaly. The NIC400 bus to also expected to be fairly large, but may be best for this to be merged into the top hierarchy as it will likely be distributed across the entire chip. 

In terms of IO; we are expecting that the die will be about 2.2 x 2.2 mm, using a bump pitch of 200um we can have a total of 121 IOs (linearly arranged). The number of IOs to be supported by the SoC funcitonality is as follows:

• Clocks + resets - 3
• SWD/JTAG - 6
• QSPI - 6
• GPIO - 32
• UART (RS232) - 10
• LPDDR4 - 39
• SDIO - 7

This gives a total of 103 for the signal pins. Leaving 18 bumps for power and ground, ~ 4 per side (VDD, VSS, VSSIO, VDDIO). 

Using the equations from the datasheet given with the GPIO libraries, we can calculate based on the number of GPIO's used, that would need 16 VDDIO/VSSIO cells. We need to revisit the total number of bumps to accomodate the power supply pins needed.

For now we are going to assume that the die size stays the same, but we will reduce the bump pitch to 150 um. This would give us a total of 196 IOs. With 103 signal bumps, it leaves us with 93 available for power/ground bumps. This would give a maximum of about 23 per side (5-6 of each VDD, VSS, VSSIO and VDDIO). This now may be overkill, but in reality what we will probably do is reduce the density of bumps at the center of the die (to improve routabality on the final package).

Hierarchical Design Planning

As this is a large SoC design, we have decided to separate this into smaller sub-components that we can run the backend flows on individually. The steps are shown below

1. Import HDL
2. Initialise Design
3. Place I/Os and hard macros
4. Explore Hierarchy and commit blocks
5. Create placement abstracts
6. Continue with normal backend flow for each sub-block

The current hierarchy exploration is shown below, with the major blocks highlighted

Update 09/26

The current status of the project is shown above. The SoC architecture is almost completely finished. However, with the recent tapeout of the nanoSoC ethernet chiplet providing an alternate ethernet IP solution, we are aiming to add this IP into megaSoC V1. This which will require integration, and verification. Backend ASIC work has begun. This has been started without the full SoC being finalised. This is to ensure that when final RTL is frozen, the necessary scripts are already in place to allow for a smooth tapeout process.

The full verification of the SoC is still underway. One gating item is getting the SoC implemented into FPGA/HAPS to ensure that we have all the functionality we need for a linux OS to boot. Namely these are UART, timers interrupt and a boot process. The main IP that is yet to be fully verified via system integration is the JTAG debugger access port to the Cortex A53, which is often much simpler to verify when instantiated in FPGA. Once fully verified, the final backend can be run, and then verified against gate simulations, LEC, STA, as well as DRC, LVS, and ERC to ensure proper ASIC functionality.