ARM’s Fixed Virtual Platforms have become a key vehicle to enable software development for the most recent ARM processors and ARM System IP. ARM’s Fast Models for the processors have proven to fulfill the software developer’s needs in terms of execution performance, debug and trace capabilities. Even after 10 years of working with ARM on virtual prototypes, it is still surprising to me that you can boot 64-bit Android Lollipop on a multi-cluster, multi-core platform in less than 10 minutes without giving up debug visibility. Where other processor simulation approaches are motivated from the user-level software simulation, ARM Fast Models execute native software down to the lowest firmware layers including all software relevant processor details such as exception levels, MMUs etc. The fidelity enables development of a complete ARM software stack long before development boards become available.
Of course, software bring up for an ARM SoC does not stop at the boundary of the processor. Moreover tight time-to-market timelines mean that SoC software development cannot wait anymore until the SoC has been taped out. Project timelines are not the only driving factor for early software development. Late software availability causes high risks onto the overall project as SoC architecture flaws would be revealed far too late in order to correct them. Specifically, the SoC’s power management infrastructure such as the clock management units, system control processor (SCP) and the off-SoC power management IC (PMIC) are critical pieces which need significant software to be brought up and tested as early as possible. With ARM’s power state coordination interface, the software integration of the SoC power management today even goes beyond the OS, deep into the firmware. Furthermore, the increased complexity of the boot architecture with multiple boot loader stages and UEFI requires new firmware specific interface IP device drivers to be developed and tested. Thus, there is some work to be done before Android boots on a custom SoC which cannot wait until the hardware is ready.
Synopsys Virtualizer Development Kits (VDKs) are software development kits with a virtual prototype as target. VDKs embrace ARM Fast Models and there are reference VDKs available that follow the ARM FVP’s “Base” platform specification, plus allow extension and customization of the platform towards a custom SoC.
Figure 1 – VDKs are extending the software development scope from the CPU to the full SoC
The reference VDKs are binary software compatible with the FVPs and as a result the same software stack such as ARM’s trusted firmware, UEFI and Linaro’s Linux kernel can be used with these VDKs. VDKs can be incrementally extended and enhanced using IEEE 1666 SystemC TLM-2.0 compliant IP models.
A VDK is extensible through an extension interface oriented at ARM’s LogicTile Express interface. This ensures software compatibility with standard drivers for the LogicTile Express infrastructure. Transaction-level models (TLMs) representing Synopsys DesignWare Interface IP are available. Users can simply instantiate these inside a VDK:
Some of the above mentioned IP blocks are essential even for the early SoC boot phases such as the UFS or Mobile Storage flash controllers. Here, next to the main OS, drivers also need to be integrated with firmware such as UEFI. The IP models provide virtual and real world IO capabilities. As an example the USB 3 model supports up to SuperSpeed real-world IO. In this case host or device mode drivers can be developed and tested along with the real device or host on the remote side of the USB cable. The VDKs can also be connected to physical (e.g. FPGA) prototypes. In context of those DesignWare Hybrid IP Prototyping Kits, DesignWare digital core is mapped onto a HAPS-DX FPGA along with a PHY daughterboard. Now the real RTL of the IP can be used for the final validation of drivers.
Other IP is relevant to complete e.g. an ARM based micro-sever software stack. As an example, the PCie and NIC models implement the IO virtualization (SR-IOV) feature and can be used to develop low latency pass-through virtualization drivers . In the figure below, you can see a Linux-KVM based micro-sever software stack integrating DesignWare Ethernet GMAC being executed on a VDK.
Figure 4 - Complementing ARM's DS-5 with VP Explorer’s platform level HW/SW debugging
For software debugging, a VDK is integrated with major 3rd party debuggers for ARM processors, including ARM DS-5 and Lauterbach TRACE32. On top of that, the debug visibility is extended to the peripherals and their connectivity. In the figure, the DesignWare Ethernet GMAC registers are exposed next to the details of the processor and software.
In order to jump start the DesignWare IP driver integration, an entire download and build framework for the ARM’s trusted firmware, UEFI, Linux kernel and filesystem is available with the VDK. This allows software developers to immediately edit and rebuild the Linux software stack without having to search numerous community web pages with complex readme, download and installation steps. Also, the device tree kernel configuration file is automatically generated and therefore any ARMv8 kernel can be exercised without going through manual porting steps.
If you want to find out more I would like to invite you to register at TechOnLine for a live or recorded webinar on this topic.
In my next post I will elaborate how ARM FastModel based VDKs are used for SoC power management software bring-up.