Browse Prior Art Database

Methodology to Implement Independent Automatic and Random Environment for Nexus Debug Verification

IP.com Disclosure Number: IPCOM000243655D
Publication Date: 2015-Oct-08
Document File: 7 page(s) / 640K

Publishing Venue

The IP.com Prior Art Database

Abstract

This paper presents a methodology to create an independent automatic and random verification environment for nexus debug verificationHere independent means remove dependency of complex tests automatic means automatic checking of trace data from source to destination and random means to generate traces in a random manner

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 57% of the total text.

Methodology to Implement Independent, Automatic and Random Environment for Nexus Debug Verification

Abstract

This paper presents a methodology to create an independent, automatic and random verification environment for nexus debug verification

Here “independent” means remove dependency of complex tests, “automatic” means automatic checking of trace data from source to destination, and “random” means to generate traces in a random manner.

Background

In a multi-core System On Chip (SOC), traces generated from various clients like the processor cores, data path system, Corenet system, ocean system, and DDR can egress either to an external debug port like Aurora or be stored in system memory after arbitration.

The following major challenges are faced:

1.     It is a difficult job to generate traces from all clients simultaneously in a desired manner because there are a number of different complex debug clients (core, datapath, main fabric, etc.). Unique test/stimulus is required to generate traces from each client.

2.     Manually checking of trace sanity is complex and error prone.

3.     Issues seen in silicon are difficult to produce in verification simulation.

4.     Checking of arbitration scheme of main funnel (NPC) is important when multiple clients are enabled.

5.     Random traffic to catch hard-to-reach bugin design.

Body

Methodology includes below steps:

•      Replacing all nexus source clients with nexus driver. (i.e., cores, FMAN, QMAN, etc.)

•      Driver is generating traces in nexus format. We can configure the number  of messages in a random interval.

•      Each driver has source id that is define by AD, embedded in nexus message generated by them.

•      Able to generate desired scenario in verification environment. We can configure each driver for generating a particular message defined by specification.

•      Checks arbitration logic exists in main funnel (NPC).

•      Automatic end to end trace data and source id checking.

•      Removes dependency on other team for stimulus.

•      Random traffic to catch corner bugs and collecting coverage at interface.

•      Reduction in compile time and simulation time due to source client are stubbed.

 

            

Figure 1 - Nexus Debug Verification Environment with Driver & Checker

Figure 2 - Nexus Debug Verification Environment with Checker Only

Figure 3 - Block diagram...