The Synopsys HAPS® System adds additional capabilities to the FPGA-based prototyping environments SoC Labs can use to support projects. The HAPS® system provides a greater amount of logic resources supporting the development of larger SoC designs. It can be used to support multiple projects simultaneously. It is used by many semiconductor companies, including ARM, for their CPU verification. This collaboration project will use the HAPS® system in SoC Labs projects and share with the community experience in utilising such systems.

A Xilinx ZCU104 ZYNQ UltraSCALE gives a capable environment for developing the nanosoc reference design. As larger reference designs are developed, they require larger FPGA-based prototyping environments to assist in their development. While a nanosoc based SoC design can be completed by a single person with a dedicated development environment, larger SoC designs require a team approach and a shared development environment. Team based development can use HAPS systems for a variety of roles in the SoC development cycle:

• verify the synthesizable RTL source code of larger SoC designs
• SoC Labs already uses a Continuous Integration and Deployment for verification approach where a virtualised environment builds the developing SoC design and regularly exercises it in a Design under Test environment. The HAPS system will improve this capability.
• support hardware/software co-design by supporting developers to write and test software on emulated SoC designs

In SoC Labs, the HAPS environment is used to support the bring-up and validation of the megaSoC reference design. This work builds on the existing use of HAPS for SoC verification and software development by introducing a structured, staged bring-up methodology that improves observability and reduces debug time.

Setting up the HAPS system

The HAPS-SX is served by a gateway machine, haps-dev, which carries the board’s USB connections (JTAG, serial consoles, SWD) and tunnels the board’s services to the development servers over a private board subnet. Nobody plugs a laptop into the chassis.

Board configuration is done in Synopsys ConfPro-SX: HapsTrak connector voltages, global clock frequencies and enables, the DDR clock, programming mode, JTAG routing and reset. SoC Labs has modified ConfPro-SX for multi-user operation; on the development server a single module load haps-dev provides it together with the programming, hardware-server, OpenOCD and board-lock commands. A WSL build is being set up so the board can also be driven from a laptop.

Programming is over Ethernet through ConfPro-SX. A VU19P bitstream (about 100 MB) loads in 20 to 60 seconds, against many minutes over JTAG. Vivado’s hardware server runs on haps-dev against the board’s physical JTAG and is used for ILA and VIO debug only.

The board is shared through a lock: haps-board-lock acquire -d <minutes> before a run, release after. A reservation always carries an expiry, so a forgotten lock cannot block the board. The HAPS-SX Development space on the SoC Labs Confluence holds the runbooks: getting started, network and command-line configuration, adding a board, HOSTIO and OpenOCD debug, ConfPro-SX on WSL, and the DDR memtest procedure.

Debugging SoC's in HAPS

The Xilinx Virtual Cable (XVC) can be used for both hardware and software debugging of the SoC being emulated in the FPGA. The software debugging is achieved by using a JTAG to AXI bridge. This takes the JTAG from the XVC into a debug wrapper. Within the debug wrapper an AXI bus can be  instantiated with various debug components. Below is diagram of a basic configuration with a JTAG component, which could be connected to the Debug Access Port (DAP) of the SoC and used for software debugging, alongside an AXI-UART component that can be used to read/write to the stdio of the SoC

The JTAG to AXI component can be controlled using TCL commands in the vivado hardware server. A simple example of this is shown below

reset_hw_axi [get_hw_axis hw_axi_1] # reset the axi component
set address 0xC0000000
set rt axi_bram_rt
set wt axi_bram_wt

# Setup read and write transactions
create_hw_axi_txn $rt [get_hw_axis hw_axi_1] -type read -address $address -len 4
create_hw_axi_txn $wt [get_hw_axis hw_axi_1] -type write -address $address -len 4 -data {44444444_33333333_22222222_11111111}

# Write data
run_hw_axi [get_hw_axi_txns $wt]

# Read data
run_hw_axi [get_hw_axi_txns $rt]

Using this approach, tests can be written in TCL to verify the system that is instantiated in the FPGA. The System ILA can monitor the AXI transactions, an additional ILA can monitor things like GPIO from the SoC. 

In addition to the JTAG-to-AXI debug wrapper described above, initial bring-up of a new design can use an Integrated Logic Analyzer (ILA) instantiated directly in the top-level RTL. This provides immediate visibility of core health signals — clock activity (via a heartbeat counter), reset release, UART transmit activity, and QSPI chip-select — over XVC, without first having to bring up the full AXI debug infrastructure. It is a lightweight first step that confirms the clock path and basic liveness before more detailed AXI-level debugging.

For designs with a Cortex-M debug port, a DAPLink on PMOD2 is served by an OpenOCD server on haps-dev, giving GDB access without the JTAG-to-AXI path; the nanoSoC DDR memtest is driven this way.

Bring-up and validation of the megaSoC reference design

The current work focuses on bringing up the megaSoC platform in a controlled and observable manner. Rather than relying immediately on full software execution, the system is validated incrementally at the hardware level.

Key integration work includes:

• Development of a top-level wrapper (haps_top) providing:
  • clock distribution
  • reset sequencing
  • real-time clock generation
  • heartbeat generation
  • UART routing
  • QSPI pad breakout
• Integration of the peripheral subsystem including GPIO, timers, SPI, and UART
• Validation of interrupt mapping
• Establishment of simulation-based debug infrastructure

The detailed design-flow documentation for this work, including the full pin map and the RTL adaptations, is on the megaSoC Prototyping using HAPS-SX page. The full megaSoC tape-out RTL now runs on the HAPS-SX under FPGA-only overlays (SRAM macro models, clock-gate pass-through, DRAM error slave or DDR4 wrapper, UART0 bypass). Bring-up has found and fixed several independent design defects, including a boot ROM firmware bug that would have been silent on silicon and a power-domain Q-channel tie-off that held the ROM in reset. The ROM domain now sequences and the boot ROM serves instructions to the Cortex-A53; [boot banner observed on the console / boot banner confirmation is the current step]. Detail is on the megaSoC project page (Update 10/26) and the megaSoC Prototyping using HAPS-SX design-flow page.

Debug Flow

Before generating a bitstream, the system is validated in simulation to confirm that core subsystems are operating correctly. To avoid unnecessary software debugging and ensure hardware correctness, this step-by-step process is followed:

In simulation (before bitstream generation)

1. Verify clock and reset behaviour
2. Confirm heartbeat and internal counter activity
3. Observe CPU AXI fetch traffic
4. Validate boot ROM responses and the start of the boot sequence
5. Observe peripheral bus activity (GPIO/UART configuration writes)

On HAPS hardware (after ConfPro configuration and programming)

6. Confirm the clock path and reset via the heartbeat (LED and/or ILA)
7. Observe UART0 transmit activity
8. Read boot output on the serial console, reached through haps-dev’s USB-UART on PMOD3 at 115200 baud.
9. For DRAM-equipped builds, read the calibration-done bit from the DRAM wrapper’s APB status register, then run the shared memtest over OpenOCD.