| |
 | |  | | | | | Incisive Generic Software Adapter (GSA) Product Review
Ernst Zwingenberger
El Camino GmbH | |
| |  | |  |
Length of experience with the product
1 year
Types of design with the product
ICs for applications in consumer electronics
Other products used in the design flow
Incisive Formal Verifier, Incisive Unified Simulator, Incisive Specman Elite, Incisive Enterprise Manager
Product Overview
The Generic Software Adapter (GSA).is part of the Incisive Software Extensions (ISX). ISX is part of the ESL Verification solution that was announced by Cadence in Dec 2006.
GSA extends Specman Elite to drive and monitor software in the same way that is done for hardware. With GSA software calls or internal signals can be bound to e ports like HDL signals. This allows the user to cross hardware and software coverage items and a reactive stimuli generation dependant on hardware or software states.
Installation and configuration:
The installation and configuration of GSA with the help of a Cadence engineer took us one day.
Documentation and help:
So far there was no need to look into the documentation.
Ease of use:
Once GSA framework is configured, it is very easy to access software internals or add new software calls. From a test writer point of view there is no difference now between hardware and software tests.
Performance:
GSA allows host code execution of the software, which results in a very good performance because just the interaction between software and hardware consumes simulation cycles.
Results:
Any trained engineer who’s familiar with writing coverage driven test benches on hardware is now perfectly able to write a coverage driven verification environment for software or HW/SW co-simulations. Also for a test writer there is no difference now to do a software call or any hardware interface transfer or hardware register access. There’s no need to know C because the software adaptor hides it. The software adaptor also makes it so you don’t have to compile C code. The C code is precompiled. Throughout the verification flow, there’s far less work. You have fewer tools and scripts to maintain. Everything is in your test file. You can just load and use it.
With GSA we have been able to deliver a HW/SW package to the chip-level integration team very early in the design process in a quality which is noted for coverage driven verification methodology. Instead of configuring the thousands of hardware registers of our sub-system the chip-level engineers just call a set_application_mode() C routine.
| What's good
With GSA we reach a new level of abstraction. The border between hardware and software disappears. Now when we talk about a DUT it could be hardware, software or a mix of both. Coverage driven verification is not longer limited to hardware verification.
What could be better
The handling of complex C routines with pointers or structs as parameters or return values should be improved.
About the author
Ernst Zwingenberger is currently head of R&D for Verification at El Camino GmbH. From 2004 to 12/2006, Ernst was System On Chip Verification Engineer, responsible for Coverage Driven Verification Methodology, verification concepts and verification project leading at Micronas GmbH in Munich. Prior to that, he was a Specman Consulting Engineer at El Camino GmbH (Verisity Alliance Partner) where he worked with:
- Force Computers/Munich: eVC for a 64bit/66MHz PCI to PCI bridge ASIC
- Ericsson/Nuremberg: eVC for a UMTS downlink baseband processing ASIC
- Ericsson/Nuremberg: System (board) level eVC for a UMTS Downlink Baseband Processing Board
- Philips/Starnberg: eVC for a SXGA Controller for TFT Panels
- Ericsson/Gothenburg: eVC for UMTS Highspeed Downlink Packet Access (HSDPA) Media Access Layer (MAC) Software
- Infineon/Munich: eVC for a mobile phone chipset
Ernst Gratduated in Electrical Engineering at the University of Applied Sciences Landshut, Germany. |
| |
This content has not yet been rated by other users |
|
|
|
|
|
|
|