As always, we must continue to reduce the time-to-market of SoCs and complex systems. An FPGA prototype implementation of these systems can be used as a basis for early software or firmware development, hardware-software co-verification and system validation, and all this can be achieved before actual silicon is available. As FPGA prototyping systems can also be used as a platform to validate system level functionality and are fast enough to develop application code running on top of an OS, the adoption of FPGA prototyping systems is increasing.
An important part of system level validation is to ensure that the performance meets expectations and that the system is capable of supporting anticipated workloads. In order to validate critical scenarios it is important to accurately model the clock-level timing of target memory types such as DDR4, DDR5, LPDDR4 and LPDDR5, so that the whole-system effects of running with different levels of memory subsystem loading can be observed, albeit at a scaled frequency. This article focuses on how Memory Softmodels are used in the validation process and how they provide the foundation for performance validation accuracy.
INTRODUCTION
The size of SoCs and complex systems is growing rapidly as more and more IP blocks and sub-systems are integrated to reduce overall system development cost. This trend demands increased efforts in both hardware and software validation. This has created the requirement to start validation of the system and its related software as soon as possible, in order to be able to meet the relentless drive to reduce time-to-market. As FPGA prototypes can represent a frequency-scaled replica of a design running at an actual speed, it can validate a comparatively mature RTL and provide a platform to start early development of the software to be executed on this RTL. Hence, FPGA prototyping systems provide a very effective solution in reducing time-to-market. Further it reduces costly design re-spins by validating and eliminating bugs in the design before the availability of actual silicon. The representation of a design on an FPGA prototyping system needs to be clock-cycle accurate to realistically determine its performance.
UNDERSTANDING THE VALIDATION PROCESS
In an SoC development cycle, Verification and Validation each play an important role in proving a design’s quality against its golden reference specification. Verification is a process in which a design is tested against its specification, with the main goal being to ensure the functional correctness of a design. On the other hand, validation is a process to make sure that the design fits its system level purpose and performs as it was intended to. Ultimately, validation is performed with the final silicon to qualify the design for all of its functionality within the required performance window.
Any form of validation, whether it is intended for system level validation or to run software stack on processor hardware, requires some form of memory. There are various ways in which the memory resources can be implemented in a FPGA prototype. It can be done using either resources internal to the FPGA, or by using on-board external memory devices connected to the FPGA. The applications that use a small amount of memory, i.e. up to few Kilobytes, can target internal FPGA resources. However applications which require memory resources of Gigabytes, would use on-board memory for bulk memory storage. A Memory Softmodel comes with a pre-packaged solution for interfacing to the bulk memory devices on the FPGA prototyping system.
 |
Figure 1 - Subsystem-level Memory Abstraction Using a Softmodel
A Memory Softmodel can provide sub-system level memory abstraction as demonstrated in Figure 1. In this setup, the Memory Softmodel is implemented as an AXI slave and the DUT system accesses the on-board DDR memory by generating appropriate AXI traffic. This configuration is typically used to replace a memory controller sub-system in an SoC pending the arrival of the RTL. It provides access to bulk memory storage for the designers to start early development of the software, but this is an overly optimistic solution as the impact of DDR latency is completely ignored.
An important part of system level validation is to run the system under various traffic scenarios to determine if it is capable of supporting anticipated workloads under different system configurations. To be able to get a realistic idea of the system’s throughput it is important to have a setup that accurately models clock-level timings of various target memory accesses. Clock-level timing of a memory access is the memory’s configured latency at which read or write data is available from the point when the memory access is initiated. Using a clock timing accurate memory abstraction can help in determining key system characteristics such as the system’s throughput and its performance under different workloads.
 |
Figure 2 - System-level Memory Abstraction Using a Softmodel
A DDRx or LPDDRx Memory Softmodel is a clock timing accurate model with a protocol compliant port list. When used with a target DDR controller, it provides memory abstraction and helps in creating accurate scenarios where the system’s throughput can be measured realistically. It supports all the protocol features required for system level validation, which can be useful in determining system’s performance under different memory configurations. For example, a Memory Softmodel can be used to determine the impact of different read and write latencies on system level throughput and to ensure that with each of the required configurations the system’s behavior aligns with expectations. Different performance characteristics can also be measured by trying different combinations of clock frequencies, different memory data widths, densities, and other functional configurations. This allows hardware implementers and software developers to optimize the system level design for the desired throughput. In the early parts of the development cycle it helps to make critical design-specific decisions by determining optimum configurations to achieve the required throughput.
The Memory Softmodel decodes the traffic from the memory controller, creates a logical address for each requested memory access and, based on the current configuration set by the controller, forwards or accesses this converted traffic so that it can be stored or read back from an on-board DDR resource. This eliminates the need for the FPGA prototype to provide on-board storage memory devices that match the memory type targeted by the DDR controller.
Many DDR controllers improve their throughput by changing how they map a logical address to a DDR physical address, made up of the bank, row and column registers. A Memory Softmodel has a built-in configuration feature that allows different physical mappings to be translated back to a logical address, making it easier to check memory content via the backdoor interface. By experimenting with various memory mapping schemes, developers of DDR controller hardware and software can also explore how different memory mapping schemes impact the system throughput and determine the best configuration to maximize throughput for the anticipated memory traffic.
FEATURES OF A MEMORY SOFTMODEL
The Memory Softmodel is encapsulated with features such as wrappers to provide backdoor accesses to the main memory, to protocol specific configuration registers, and to the Memory Softmodel specific place and route constraints within a single package. This can simplify integration of the Memory Softmodel with any DUT system, so the Memory Softmodel can be directly used as a plug-and-play solution. Support of backdoor accesses to the on-board memory can be a used to load/unload memory images to the on-board DDR, which can be very useful in providing bulk memory storage for important scenarios such as validation of the system boot process.
Backdoor accesses to the protocol-specific configuration register can be very helpful to understand the current status of the Memory Softmodel mode register configurations. This provides a quick way of debugging to eliminate issues such as differences in the Memory Softmodel configuration compared to the expected configuration set by the controller. A Memory Softmodel can also be configured to overwrite some configurations via backdoor accesses, which otherwise would require a whole recompile of the design.
Optionally, a Memory Softmodel can be configured to inject errors by modifying its configuration using backdoor access. Normally an error isn’t expected to happen, but it is important to determine the system’s behavior in case of such errors. It helps in ensuring that the system can withstand and recover from the error conditions as expected and still be able to provide necessary performance for the workload. This can be used to make the system more robust to qualify for various usage scenarios.
 |
Figure 3 - Using a Softmodel in an example
To conclude, consider the validation of an example SoC aimed at a mobile application. The required Android boot image can be loaded on the FPGA prototype on-board memory via backdoor accesses to the LPDDRx Memory Softmodel and then the DUT can immediately initiate the process of booting via reading back the boot image from memory. After booting is completed, the system can be run under different traffic scenarios to determine if it can handle different workloads as expected and is able to meet its performance requirement under such workloads. If not, configuring the system with different memory latencies can be used to characterize the system’s throughput with each value of latency. This can be helpful in making decisions for any possible design change. Even in the case of the system’s meeting its throughput requirements, further optimization is possible to achieve the best possible throughput. In cases where different blocks of the system are still under development, software validation can still be started early by replacing the memory sub-system with an AXI-slave Softmodel. Software executables can be converted into hex which is fed to the system to generate required application-specific scenarios.
Mentor’s Veloce Prototyping System (VPS) provides an expansive library of Memory Softmodels with generic and protocol-specific solutions for these applications. Since these Memory Softmodels are in compliance with the protocol specification, they can also be retargeted to run on Mentor’s Veloce emulation platform.
Back to Top
