Verification of Multi-Port SRAM Controller with AXI Interface

A high-performance multi-port SRAM controller verified using SystemVerilog and Python-based analysis monitors to evaluate latency, hazards, and arbitration under concurrent traffic.

View SystemVerilog Code Explore Architecture

Objective

Verify a multi-port SRAM controller that supports simultaneous access through multiple ports connected via an AXI interface. The aim is to ensure correctness, consistency, and performance under high traffic conditions.

Use Case

Common in high-speed SoC designs, memory subsystems, and AI accelerators, this controller enables concurrent read/write operations across multiple master ports such as CPUs, GPUs, and DMA engines.

Architecture Overview

Multi-Port Access

Independent read/write ports, each with dedicated address and data buses.

Arbitration

Fair scheduling logic using a round-robin algorithm with priority overrides.

Hazard Management

Implements RAW, WAR, and WAW hazard detection via address tagging and replay logic.

AXI Interface

AXI4-Lite compliant bridge ensures protocol-level reliability and timing accuracy.

Verification Methodology

Developed a modular SystemVerilog testbench with TLM agents.
Used Python monitors for runtime latency profiling.
Scoreboard for checking data integrity across ports.
Functional coverage for access types, hazards, and arbitration scenarios.

Tools & Setup

Simulator: Synopsys VCS / ModelSim
Languages: SystemVerilog + Python
Interface: AXI4-Lite
Automation: Python analysis & report generation

Sample SystemVerilog Code


module sram_controller (
  input  logic        clk,
  input  logic        rst_n,
  input  logic [3:0]  addr_a, addr_b,
  input  logic [31:0] wdata_a, wdata_b,
  input  logic        we_a, we_b,
  output logic [31:0] rdata_a, rdata_b
);
  logic [31:0] mem [0:15];

  // Write Operations
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      integer i;
      for (i = 0; i < 16; i++) mem[i] <= 0;
    end else begin
      if (we_a) mem[addr_a] <= wdata_a;
      if (we_b) mem[addr_b] <= wdata_b;
    end
  end

  // Read Operations
  always_comb begin
    rdata_a = mem[addr_a];
    rdata_b = mem[addr_b];
  end
endmodule

Results

Verified multi-port concurrency under random stress patterns.
All hazards detected and resolved correctly.
Latency distribution shows 2.3–2.5 cycle average per transaction.
Functional coverage: 98.4% across key features.

Conclusion

Verification confirms the controller’s capability to handle concurrent AXI transactions with high integrity and efficiency, suitable for multi-core and accelerator-driven SoCs.