The Agilex™ 5 HPS component in the virtual platform is an Intel® Simics® model that corresponds to the Hard Processor System Agilex™ 5 FPGA IP in the Quartus® Prime software. The hierarchical name of the HPS component in the virtual platform is system.board.fpga.soc_inst.hps_subsys.agilex_hps.

The Intel Simics simulator for Intel FPGAs supports the model of the Agilex 5 HPS Component for the Agilex 5 E-Series device and the Agilex 5 D-series device. You can select which model to use when specifying the stepping configuration parameter in the virtual platform target script, as Agilex 5 Universal Virtual Platform User-Configurable Parameters indicates.

The HPS component consists of the following main functional blocks:

• MPU Subsystem: The HPS component includes a HPS microprocessor unit (MPU) model. The MPU in the Agilex™ 5 SoC FPGA HPS consists of two Arm* Cortex* -A55 cores and two Arm* Cortex* -A76 cores.

  The model of the cores executes the HPS embedded software binaries, and the execution of these binaries directs the simulation flow. You can adjust the parameters of the HPS component to select the boot core to use and the power state of each core, similar to the settings you have in the HPS IP in Quartus® Prime software. These parameters are defined in the target script that configures the Intel® Simics® HPS model.

• OCRAM: The on-chip RAM (OCRAM) in the HPS is the initial boot device for the HPS.

  In hardware, the first stage bootloader is provided as part of the bitstream which the SDM consumes. The SDM loads the bootloader into the OCRAM and takes the HPS out from reset so the HPS can start executing the bootloader code. Because the Agilex™ 5 Universal Virtual Platform does not fully model configuration, the image of the first stage bootloader is loaded directly into the OCRAM. The target script specifies the path of the first-stage bootloader image as a parameter.

• Flash Controllers: The binaries to be executed by the HPS are stored in a flash device. The flash device can be a NAND memory, an SD card, or a QSPI memory.

  To access these flash devices, the software running on the boot core uses the flash controllers to read the next boot stage software binaries from the flash device and load them into the SDRAM. The Intel® Simics® model of the flash memory devices is part of the board component. A board component can supply an image to be loaded into that flash device. The image is defined as a user-configurable parameter provided as part of the target script.

  Note: In the Intel® Simics® model of the Combo PHY, the interface between the SD card/NAND flash device and the corresponding host controller is performed at the transaction level through API calls rather than a physical level.

• UART Controller: The Intel® Simics® simulator includes a serial console that you can use to interact with the software running on the target system. To enable the serial console, the HPS component of the Intel® Simics® model includes an Intel® Simics® model of the UART controller. Use the Intel® Simics® Serial console connected to the UART to view messages created by the software running in the HPS and provide input to the U-Boot or Linux prompt. The serial console is created by default in the target script, but you can also disable it through a target script parameter.

• Ethernet Media Access Controller (MAC): The virtual platform supports Ethernet connectivity using the TSN controller, enabling eth0 Ethernet link.

  In the virtual platform, an Intel® Simics® service node component provides network services in the simulated target system and provides connectivity between the host machine and the target system. The service node is instantiated as part of the target script. The Ethernet media access controller (MAC) interfaces with the service node through the Intel® Simics® models of the Ethernet marvel PHY device and an Ethernet port. Both are instantiated as part of the board component. Several kinds of connection between the simulated network and the physical ("real") host network are supported in Intel® Simics® .

  For more information about networking capabilities in Intel® Simics® simulations, refer to Networking with the Simulated Target System in the Intel® Simics® Simulator for Intel® FPGAs User Guide.

• General Purpose I/O (GPIO) Interface: The virtual platform supports GPIO functionality through the GPIO0 and GPIO1 ports modeled as part of the HPS Intel® Simics® model. These ports allow the GPIO pins to be configured as input or output.

  There are use-cases and applications that make use of these ports that allow some interaction with board-level components. The Agilex™ 5 Universal Virtual Platform also offers a GPIO loopback model in which pairs of pins are tied together to emulate a loopback configuration. The loopback support is provided as part of the board component.

• HPS-to-FPGA Bridges: The virtual platform implements an example design connected to the HPS-to-FPGA bridges corresponding to an Intel® Simics® model of the FPGA fabric in the Agilex™ 5 GHRD.

  The fabric design includes an On-Chip Memory IP connected to the HPS2FPGA bridge and a peripheral subsystem integrated by the models of three parallel input/output components (dipsw_pio, button_pio, and led_pio) that are connected to the LWHPS2FPGA bridge. Software running in the HPS can access the components in the fabric example design by accessing the memory address range in which these are mapped under the FPGA component.

• FPGA-to-HPS Bridges: The virtual platform includes a few bridges that connect the FPGA logic with the HPS (FPGA2HPS) and the SDRAM (FPGA2SDRAM). Under the FPGA logic, few memory spaces were created that are used as an initiator for write and read operations to the HPS and SDRAM components.

• I2C and I3C Controllers: You can configure them as hosts accessing the I2C or I3C devices connected to the buses. The I3C controller also supports connecting legacy I2C devices.

  The type of devices that can be connected to the bus are smart sensors and flash memories such as EEPROM. The I3C controller can be configured as a host or target device. Several instances of the controllers are implemented in this virtual platform to match real hardware architecture. All the instances of the I2C controller are used as general-purpose I2C controllers. While I2C controllers in real hardware can be used as a control interface for Ethernet transceivers, using I2C controllers is not supported in this virtual platform.

• USB Controllers: USB 2.0 OTG and USB 3.1 Gen 1 USB controllers are supported, which offer the following features:
  • Support hot plug (plug and unplug) during simulation.
  • Allow access to mass storage devices when used in host mode.

  The USB 3.1 Gen 1 controller provides host functions to access high-speed and super-speed devices and supports Dual Role Device (DRD) feature that allows switching between host and device mode through plug/unplug Simics commands. A single Type-C connector is provided in the virtual platform, working as a USB 3.1/2.0 host or device at any given time.

  The USB 2.0 OTG supports a single USB port connected through a USB 2.0 transceiver with high-speed devices. It also supports configuring as a device, allowing switching between host and device modes through plug/unplug Simics commands.

• SPI Controller: Two instances of the SPI IP are configured as host (SSI HOST) and two instances as target (SSI_DEVICE), enabling serial communication with any SPI board device. These devices can be flash memories, EEPROMs, or sensors.

• Power Manager: Supports powering on the user-defined boot core. You can select the combination of CPU cores to use in the application using the target script and emulate the settings coming from bitstream. Similar to hardware behavior, these settings are static and cannot be changed later in the simulation. Only core 0 and core 2 can be configured as boot core.

• Reset Manager: Supports a number of different HPS reset types, such as cold reset, warm reset, and watchdog timer reset, handling the reset sequence flow for each one of these resets.

• System Manager: Contains logic to control system functions and other modules that need external control signals provided as part of system integration.
• System Memory Management Unit (SMMU): Translates input addresses to output addresses based on address mappings defined in translation tables. This component supports the following translations:
  • Stage1 translations (input virtual address to output or intermediate physical address)
  • Stage2 translations (input intermediate physical address to output physical address)
  • Combined Stage1/Stage2 translations

  Table walk is used for each stage of the translation.

  The address translation supported can be secure and non-secure. This component also supports bypass mode.