Virtual Prototyping Platform with Flash Memory

Sachin Ghadi, Sagar Kadam,
Open Silicon Inc. (Pune India)

Abstract:

Hardware-software co-design is an integral part of SoC development flow. Besides traditional prototyping methodologies like FPGA prototyping, virtual prototyping has emerged as a convenient and low-cost platform for early system design, software and firmware development. Virtual prototyping provides an environment for software development, design optimization and also a testing framework using scripts and debugger tools. This reduces the necessity of costly equipment and boards needed in developing boot code or application code for any embedded system. Even if the RTL for an IP is verified in the most stringent verification environment, having software run over it gives a better analytical report. Unavailability of such environment may limit the verification activity.

Most SOCs have uniquely defined memory subsystems consisting of high speed, low speed memories, static and dynamic memories. In addition to data storage, these memories also play vital role in providing different booting options to SoCs. In this paper we will see how the flash memories developed using Carbon Model Studio helps to bring up an ARM® Cortex A7 flash memory sub-system with primary and secondary boot codes. Flash memories system demonstrated here can be used for early boot code and driver development for any CPU based SoC.

I. INTRODUCTION

Every SoC designed needs to go through rigorous verification / validation testing at many stages. Different EDA tools available into the market aid the silicon validation process. These tools can contribute in Soc validation to some extent; while software based validation techniques need to be used for functional validation of the IP’s and verification of the system; also termed as pre and post-silicon validation. FPGA prototyping is largely currently used as one of the medium for pre-silicon validation. But it has its own pros and cons involved such as cost

development of extra daughter boards, limitation of running design at given speed, fitment of design in FPGA etc. Daughter boards mainly contain end devices so as to validate the controller IP’s. End devices may contain usb/pcie sockets/slots, network connectors, or storage devices like Flash memories. Memories are an inevitable part of any SOC based system, be it volatile and non-volatile memories. Also the complexity involved in developing code in order to access them is also high. It is time consuming, costly and complex to design a hardware which has flash memory support. For a hardware system many factors need to be considered such as:

Type of memory.
Clocking circuitry to these memories/controllers
Sockets for mounting the memories
Pin connections, multiplexing
Programming of memory devices using in-circuit and off board programing methods.
Reliability in case of limited Program/Erase cycles

This system can be used in early software development, where system specifications have been freezed and RTL development has been started, thus effectively using the engineering resource bandwidth. Figure 1 below shows a generic life cycle for a SoC development and verification. The time incurred for a verified SoC to go to a production phase varies from 10-18 months, depending on the specs for which the SoC is designed. Once the sample’s for the designed SoC are made available, system developers come into play. The hardware and software design team nearly takes another couple of months at a minimum. The chip bring-up activities and software verification can be done faster if virtual prototyping is used. Using virtual setup the framework and software stack can be developed even when the hardware is not available. Virtual prototype Development can go hand-in-hand along with the RTL design.

Figure 1: Generic Life Cycle of SoC Development and verification

To overcome these hurdles, we developed virtual models for flash memories which are also a cost effective approach.

We developed a complete SOC subsystem on canvas using carbonized models from actual IPs. The flash memory is a generic memory subsystem consisting of SNOR, SD, eMMC, NAND and DDR3 memories, and memory controllers along with Cortex-A7 processor, interconnects, resetting and clocking logic and configuration registers.

Carbon’s ModelStudio tool is used to create carbon model from controller IPs but it needs its memory counterpart to complete end to end use case. As Carbon platform needs synthesizable RTL for creating models out of Model studio, normal behavioral memory models used in verification environment cannot be used here. Flash memory subsystem has following components integrated on demo SoC Platform.

CPU
UART
NIC
Resetting and clocking block,
IO mux
LPDDR3, SD-Host, NAND and QSPI controller and respective memories.

This design is based on the one Camera chip design we did for one of our customer.

Software developers can immediately start writing and validating their bootcode which would be placed either into bootrom or secondary storage memories. An abstraction layer is developed and verified beforehand for different types of memories, and can be easily ported if the flash memories are changed.

II. FLASH MEMORIES

The Carbonised memories developed from synthesizable rtl are cycle accurate and abide to the protocols defined by the specific standards.

SD Memory: The SD memory supports following features

Supports SD specification 3.0
Interfaced with SD Controller.
4-bit bus width.
Single and multi-block memory read write.
Storage up to 2MB(can be expanded)
Supports DDR transfer

NAND memory:

Supports ONFI 1.0 standard interface and command set
Supports Data width x8
Page size 2K + 64 bytes spare area
Block size 64 pages
Supports page program/erase
Supports random data output
Supports register and ID read commands

SNOR memory: SNOR memory is based on Spansion memory; its features are listed below

Interfaced with QSPI Flash controller over SPI bus
Supports SPI/Dual/Quad bus modes
Supports Simple mode read/write access to memory
Status and configuration registers available for back door read/write

eMMC memory: eMMC memory features are listed below

Supports JESD84-B451 standard.
Supports 8-bit data mode, storage size up to 1MB.
Supports Class 0, 2, 4 command sets.
Set of registers for operation control and status.
Supports DDR transfer

III. CASE STUDY

As a case study, we demonstrated how in-house developed SD memory model had been used to develop primary and secondary boot code. The following image shows how a dual core CortexA7 CPU is connected to different memory controllers through NIC fabric. Our aim was to develop a production level bootrom code (viz primary bootloader) which can decide on the fly whether to boot from SD/eMMC/NOR/NAND memory. In general system a GPIO based jumper settings are made available which decides the memory from which the secondary bootloader should be loaded. In our virtual platform using a boot mode register model designed to duplicate this scenario.

Figure 2: Cortex A7 Flash memory sub-system

Primary Boot code:

This code does the required initialisation of the CPU, stack, heap, LPDDR and other necessary peripherals. Bootcode reads the boot mode selection register and decides whether to use secondary bootcode from SNOR/SD/eMMC/NAND memory and uses the abstraction layer to access and copy the firmware from either of these memories into LPDDR.

^{Click to enlarge}

Figure 3: Bootcode and firmware in execution

In Figure 3 we demonstrated loading and execution of primary boot code from internal ROM and secondary boot code from either of the memories. In order to get a full-fledged embedded linux running on the system, u-boot is used as a secondary bootloader. We were also able to get a functional u-boot running on our system.

U-boot placed in external SD memory/SNOR/eMMC/NAND is copied into LPDDR and executed from there. The below image shows U-boot being executed as secondary boot loader.

^{Click to enlarge}

Figure 4: U-boot in execution.

We had specific requirement of booting the SoC in required time. From this exercise we could estimate total booting time required from start of the system because of its cycle accuracy.

IV. OBSERVATIONS:

Using flash based memory subsystem we could enable firmware writing well ahead in soc development phase.
While carbonising memory models few test scenarios with memory controllers were identified, which helped RTL verification team to add such test cases.
We could predict the time required for the system to boot from different memories based on the cycle count observed during simulation.
In virtual platform using a modular approach it is possible to break a larger system into smaller modules, test them independently and specific drivers can be developed independently.

e.g, A single Soc can be broken down to systems based on power domains or frequency domains.

V. LIMITATIONS OF APPROACH

Having Cycle accurate models on virtual platforms gives real simulation of SOC but executing heavy foot print OS is not time effective as it takes too may cycles to execute.

Using Fast models and creating hybrid system of cycle accurate model gives some advantages over execution time.

Although we can write product quality boot code with virtual prototyping but electrical consequences like voltage switching, occurring on real hardware cannot be realized here.

VI. CONCLUSION

In this paper we explained how virtual prototyping with flash memory models proved to be an efficient and faster mode for early software development, and also how it proved an effective medium to estimate the boot up time. The SD/eMMC/SNOR/NAND memory models developed are as per the memory specifications and allows software developers to write and debug firmware level code in a virtual environment that will run as-is on platforms with actual memory.

VII. REFRENCES