Methodology to Implement Independent Automatic and Random Environment for Nexus Debug Verification
Publication Date: 2015-Oct-08
The IP.com Prior Art Database
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
Methodology to Implement Independent, Automatic and Random Environment for Nexus Debug Verification
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.
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.
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 2 - Nexus Debug Verification Environment with Checker Only
Figure 3 - Block diagram...