To enable full operating system support in megaSoC, a substantial amount of memory is required to accommodate the complexity of modern Linux-based software stacks, including the kernel, drivers, middleware, and user-space applications. Linux environments, unlike lightweight bare-metal systems such as nanoSoC, demand not only larger memory footprints but also consistent access to high-bandwidth memory to maintain performance across multitasking workloads. The most common approach is to incorporate external DRAM, which offers the necessary capacity and throughput. The use of DRAM enables the system to handle everything from file systems and networking to graphical interfaces and real-time data processing. Integrating a DRAM subsystem is non-trivial, challenge requiring the design and validation of a memory controller and physical interface (PHY) that can meet strict timing, signal integrity, and power constraints. A DRAM subsystem adds considerable complexity to the overall SoC design, both in terms of hardware implementation and system-level verification.

SoC Labs is very fortunate and thankful to Synopsys for providing access to their IP's for this project. They have supplied the Enhanced Universal DDR Memory Controller (uMCTL2) and their LPDDR4 multiPHY. Using these pre-verified IP's, should allow megaSoC to be a high-performance system with full OS support.

Specification

Before agreeing the appropriate IP with Synopsys a specification of the megaSoC system needs was developed. This enabled clear choses for the right IP for the project. The specifications included:

• Memory Type : LPDDR4
  • This was chosen as we wanted megaSoC to emulate something like the Raspberry Pi or other single board computers.
• Speed: up to 2Gb/s
  • We aren't targeting top-of-the-line computation, (otherwise we would probably go for LPDDR5). megaSoC needs enough bandwidth for reasonable applications to run.
• Bus Interface: AXI 4

After discussing with synopsys, out requirements vs. their available IP, we came to the agreement of using the uMCTL2 and LPDDR4 multiPHY.

Configuration

The IPs have a significant number of configurable options, each which add complexity to the design and verification effort. 

Integration

The design hierarchy is shown below. The top level wrapper includes a generate statement to allow for the inclusion of the Synopsys IP (or to not use it if users don't have access)

The main integration points are:

• Reset + clock control (including APB interface)
• APB interface on uMCTL2 and multiPHY
• AXI to uMCTL2
• SRAMs for PHY (this has a small CPU core to run the training algorithms)
• SRAMs for controller (buffers for write data)
• DFI interface between controller and PHY
• PHY to pins
• Interrupts

Other integration points that we are currently not focussing on:

• Scan interface to controller
• ATPG interface to PHY
• Bypass interface to PHY

All of these integration points need to be verified.

Verification

See the accordion below for all of the verification points

Reset Controller

The reset controller is a small bit of custom IP to assert or de-assert the reset and power-ok pins

The address map for this is:

• 0x00 (bit 0) - ddrphy_reset
• 0x04 (bit 0) - ddrphy_pwrok
• 0x08 (bit 0) - ddrcore_rstn

This allows for independent control of all 3 signals. Further additions could be made to add things like clock enables for the IP

We need to verify the control of each of these 3 signals

Looking at the above graph we can see

• after presetn - registers are default values (all zeros)
• At M1 - write to 0x00 sets ddrphy_reset high
• At M2 - write to 0x04 sets ddrphy_pwrok high
• Before M3 write to 0x00 to set ddrphy_reset low
• At M3 - write to 0x08 to set ddrcore_rstn high
• At M4 write to 0x04 to set ddrphy_reset high

As a very simple IP, this shows the working principle. 

APB interface on uMCTL2 and multiPHY

APB read and write to the controller and PHY is needed to control their behaviour

This one is fairly straightforward. We added an APB interface to the main system bus of megaSoC and can run read and write commands to the PHY and controller successfully

TO NOTE - the PHY data/address alignment was not to 32 bits. We had to shift the addressing by 2 so that the system bus / CPU could properly access the registers for 32 bit word aligned accesses

SRAMs for PHY

The SRAMs for the PHY are used to program the PHY training routines. There is an instruction memory and data memory

Looking at the above waveforms you can see

• M2 - programming iccm (instruction memory)
• M3 - programming dccm (data memory)
• M4 - boot started for the PHY training. Reading from iccm and dccm

Whilst this does not fully verify the behaviour of the SRAMs. This shows that they can be programmed and read from by the PHY to run the training program.

SRAMs for controller

Currently, we would only be able to observe this behaviour once the subsystem is running AXI write transactions and we have not yet got that working. For now this is on hold.

DFI interface between controller and PHY

Our first approach at this was test this using AXI based transactions. This would mean that the DFI interface is tested by functionally. However, getting it to the point of running AXI transactions is currently not working. We suspect that this is in the configuration of the PHY init training software but we can't be fully sure that it is not a problem in the DFI interface.

The slight complexity here is that the controller has a single DFI interface, but the PHY breaks it up into phases, so you have to select which bits from the controller correspond to the correct phases in the PHY. These phases are needed because of the ratio in clocks between the phy and controller (typically either 1:1, 2:1, or 4:1)

What we are currently trying to do is add a monitor that sits between the controller and PHY to ensure correctness of the connections. This monitor comes from the VC - VIP portfolio from Synopsys, we can add a UVM component to monitor signals here. 

The idea is shown above, but currently this is not finished work

PHY to pins

Check connection from PHY to pinout in testbench. This will be verified by checking that the target device in the testbench is recieving values from the DDR multiPHY. 

 

AXI to uMCTL2

After training and initialisation is complete, we should be able issue AXI requests to read and write to the DRAM. Currently we are stuck on the training and init phase.

Interrupts

Not yet decided how to test these