What is ESL

ESL stands for Electronic System Level. RTL has dominated EDA industry for over 20 years. Higher level of modeling needs are becoming very important to meet fast time to market requirements for highly complex designs which are becoming increasingly complex to validate at system level.

Electronic System Level is the high level abstraction of Hardware models in C++/ SystemC and other languages for use in design and verification flows. RTL (Register transfer level) description has been used over 20+ years to successfully design and verify development. But as design complexity has grown, conventional tools are too slow to design/ validate and release products with supporting Software. Higher level abstraction reduces Time to Market for products.

 

Modeling languages: SystemC

High level synthesis/ Embedded SW tools

As model is developed for various IPs, model developers don't know the behavior till these models are tested in Virtual Platforms or sytem level models. This leaves lots of issues in models untested and can be time consuming to find and fix. ESL development areas currently lacks support for robust testbench methodologies.

Also there is need for more constructs for HW-SW communication & SystemC driven synthesis tools that could eliminate 20 year old RTL flows.

Carbon Design Systems

For SoC designs typically IP blocks are received (like 80% design reuse) in RTL formats. Conventionally companies hire contractors to recode blocks in SystemC. For new coding RTL models are available late & converting them to SystemC could be time consuming. Companies hire consultant services to model & create SystemC models. Carbod design studio lets make SystemC models very quickly from existing IPs (in RTL)

Carbon Model Studio can save time while ensuring accuracy in modeling. SystemC coders refer to Specs & sometimes reverse engineer to model accurately. CMS allows converting RTL for OSCI-SystemC simulation. Carbon design systems offers tools to create cycle accurate models quickly from RTL (VHDL/ Verilog). RTL models are compiled into C like linkable objects that can be simulated with other OSCI SystemC Simulators.

 Following diagram shows a simple flow of converting RTL for Virtual Platforms.

I did not get a chance to investigate limitations of Carbon model studios, if any of readers would like to share some experiences, please post.
To do list:

* How to validate SystemC models against RTL? Can RTL designers use VP for reference in validation?
* Comparison to FPGA prototyping
* Investigate robustness of CMS,

About Carbon Design Systems:
Founded in:
Products:
Number of Employees:
Equity/ Financing:

Need of cycle accurate models with VP

Need for Cycle accurate models in VPs:

Majority of Firmware testing (such as BIOS) is sufficient with higher abstraction models but several portions require cycle accurate HW behavior (such as Memory training/ programming) for which SW developers conventionally waited for Si to arrive.

Performance tuning & validation: Architects have to often wait for RTL to be avail or wait for Si for performance tuning. Architects can integrate timing accurate models into their ESL models as RTL becomes available.

BIOS POST Code Testing

BIOS POST codes are still relevant and a Virtual Platform Engineer might spend some time as engineers bring up the platform for first time. So its important to know the basics. Recently BIOS is being replaced with EFI.

When Computer boots, pre-boot code executed is called Power-On-Self_test. When a machine is powered on, its tested for basic functions with a special BIOS code called POST.  For a PC, BIOS reports messages on IO port 80. Using post-code, it can be identified what's going on in the machine.

Using a BIOS diagnostics card (e.g. PCI based card etc), Post codes can be displayed on a 2 segment LED display. Codes can be deciphered from BIOS manuals to understand what's going on in the sequence.

Here are some manuals that can be found on Phoenix/ AMI websites:

Phoenix technologies: Medallion BIOS™ Version 1.00

AMI: AMIBIOS8

APTIO: AMI

As an example, while working with my virtual machine, I reached boot sequence post code F4, which meant that it's a checkpoint, where Firmware has been loaded. Some platform teams put special codes for F5-F8 for attaching various tools to virtual platforms.

Applications of Virtual Platforms

How are people using power of Virtual Platforms:

• Power On readiness
• Post-Si validation readiness
• Driver development
• Embedded OS, OS/ BIOS Development

Virtual Platforms offers capabilities to Analyze, debug (visibility), controllability  over a Simulator SW Developers used in the past. Such capability is available to SW developers much before Si is available.

Virtual Platforms are not closed simulation models, but allow access to underlying physical HW such as configuring, allow visibility for debug etc. VP allows interfaces to “real world” e.g. a VP can access Internet via an Ethernet connection between VP & network in physical world; VP can talk to PCMCIA cards in PCMCIA slots of PC.Remote debugging is also possible on virtual platforms

Blogs

http://docs.google.com/View?id=ddgn5m5q_64gwg8q7fp

Hierarchical Approach to Platform Design

 

Key Terms: Hierarchical design; Platform Based Design; Block Based Designs for SoCs; Mapping Platform design to components (virtual or real).

 

One of most crucial decisions of design planning is what methodology you'd chose? A system designer creates platform level models in C++/ SystemC called Virtual Platforms. These platforms require some hierarchical approach to address following concerns:

a) Long term, it'll be desired to synthesize platform models into RTL description. Hierarchitecal design makes it possible to bridge gap between definition of a very high level model & actual implementation.

b) Platform design methodologies allow modifying SW code as its too hard to modify HW pieces in high level platform models. Hierarchical models allow to make modifications in HW along with SW.

c) its very hard to model performance in high level system models. Hier approach allows introducing performance processes as needed.

Debug on Virtual Platfoms:

Debug is a very important aspect of acceptance of VP in teams where a VP developers depends on collaboration with HW/ SW development teams.
This article discusses some of the debug hooks a VP engineer builds into the platform:

SW debug tools-

* UART: UART is a very primitive RS-232 based debug port, as system boots for first time, BIOS developers often use UART to print all debug messages on the port. PCI Config policy, Processor policy etc can be dumped, SPD from DIMMs, MRC=Memory Reference Code  on UART during run time.

* BIOS Diagnostics Post Code: A 2 segment display indicating BIOS POST codes

* Checkpoint: Code developers insert checkpoint codes to indicate flow of execution.

* Registers dumps
* Memory Dumps

Virtual Platforms

With SoC & complex systems, Virtual Platforms are gaining grounds. Processor industry is going through big change where Wintel domination was shattered with SoC/ Multi-core / Multi-processor based platforms.

As Si companies focus on providing "proven-IPs" it becomes system challenge to revenue generation. Time to Market is gated by System development.


Virtual Platforms allow SW developers to start testing their software stacks much before Si is available. VP doesn't replace need of Si, but allows early development & thus reducing TTM

VGA validation

Who needs to do VGA testing!!! Believe me, I have seen VGA testing as most overlooked validation area. And even designers often assume that IP blocks are ready to use without understanding the system level integration issues, esp in memory mapping/ space. When creating VGA validation environment, I have faced following problem numerous times in different projects:
* VGA spaced is accessed by host through IO mapped address acceses. A host control unit often fails to validate VGA space (due to legacy - always works!). Often VGA accesses will fail to arrive at proper design block. So first thing to check will be are these accesses showing up at VGA design block.

Creating an Emulator environment with Veloce:
We obtained legacy DOS based VGA tests. In a Si system, often a graphics card is plugged into PCIe port. DOS based tests access VGA thru IO mapped cycles to target card. And render outputs to display. Target design is synthesized into Emualtor box (such as Mentor or Cadence or EVE). A host PC is connected to emulator thru PCIe port (through a transactor or ICE in circuit emulation HW speed bridge board). DOS tests run on emulator.
For VGA frame sizes its a good enough setup, but for high resolution tests, it could take you "really long time" to render frames over Emulated PCIe port. Often back-door-memory accesses can speed up this testing.

Validation Strategy

You can't have a "generic" validation strategy for a project. But here is how I look at validation:

* Projects with several new features
VP/ Feature specific RP/ Emulation

* Projects with incremental new features
Emulation


????

Evaluation Criteria

For Validation tools, such as Emulation or FPGA prototyping, here is simple litmus test of a soln:
* Capacity - whats cost of building model for current gen & next gen to reduce equip cost
* Performance - what performance I get with RTL models, with co-sim such as SCEMI/DPI/PLI
* Debug - what's visibility, ease of developing debuggers for RTL designers & debuggers for SW teams
* Time to use - First models efforts, model-to-model efforts, stability etc

Why Virtual Platforms over Emulation or Rapid Prototyping

For a new project, I recommend creating a validation master plan for entire duration of project. VP may allow you to create a system level model very early in your planning cycle. And as as various pieces of platforms are developed, these can be plugged back into common VP platform to add accuracy. Use FPGAs/ Emulation opportunistically for verifying RTL with system level model. Various teams in architecture, SW development, Si design/ validation, Post-Si validation teams can utilize VP platform by replacing higher abstraction level models with more accruate models & co-simulate or co-emulate with VP platform.

I am not advocating using VP to replace everything else in validation flow. But VP offers unique capabilities which other technologies might not. So apply VP to fill validation gaps. VP allows creating a hybrid validation system which can be scalable for accuracy, speed, cost-effectiveness throughout the project.

* For Architectural exploration VP is a good technology to deploy. For new architecture definition, often RTL won't be ready for a long time. Doing Emulation or FPGA prototyping with unhealthy RTL is not efficient. VP can add clear value by providing a system level models; where architects can easily plug their models into and test them out.

* Early SW development: RTL simulators are simply too slow. Emulation & FPGA prtotyping systems are too expensive to offer reasonable models for SW teams to use. VP can offer cost effective solution

Welcome to my blog

I am a validation architect, with 15+ years of work experience in Semi-conductor industry. I have worked on various aspects of making Si chips, working in :
* Si design & validation: addressing various aspects of development cycle, from concept to real high volume manufacturing
* Platform architecture & validation: addressing new use models of new technologies these Si products offer.

Currently I am working to address various needs of a product validation with main focus on reducing time to market by finding all bugs! & finding them early! I have actively contributed my validation expertise to following areas:
* Pre-Si validation - RTL simulators
* Push post-Si validation content in pre-Si domain: Given limitations of RTL simulators what content can be pushed upstream to find bugs early. And what enabling technologies I can deploy to be able to run that content (examples: VP/ Emulation/ Rapid Proto-typing).
* Post-Si validation: how to capture all bugs in Si & be able to debug them. Work on debuggers, test content tools, etc. In addition to working on Post-Si validation tools, I have worked extensively to push the content in Pre-Si. I have also worked extensively on "Si to RTL" tools to debug & fix the bugs
* SW co-validation: How to reduce Time to market by enabling SW validation (drivers, bios, some apps stack) with RTL or with C++ models
* Architectural Exploration: Enable architects with tools to validate architecture much before RTL is available.


I am working on finding ways to reduce time to market by enabling SW co-validation, system level validation, moving post-Si validation content in pre-Si etc. I work with product development teams to deploy these technologies and reduce risk for our projects. While I get paid to enable technologies & take them in product development flows & addressing gaps which product teams might run into. I am often using new technologies to have better validation partitioning in my chip architecture - utilize Virtual Platforms, Emulation, Rapid-prototyping (FPGA), Co-Simulation, SW Co-validation etc, to address validation needs.

I'll post when I feel like publishing - I want to write papers to share my learning with rest of industry and challenge industry to address gaps left. We all benefit from mutual learning....