In simulation acceleration, there are multiple reasons for using gate-level netlists in place of RTL code. One reason is the reuse of mature code or third party IP that is supplied in netlist format because it is no longer the focus for verification, or it is too sensitive to ship as RTL. Passing netlists through tools tailored to mapping RTL is not always efficient. The sheer size of the netlist in terms of the number of files and the number of modules and design objects can stretch language compilers.
A new Application Note, How to efficiently use large netlist files with simulation acceleration, authored by Robert McLellan and Jim Tonge at Cadence Design Systems and published on http://support/cadence.com, describes the essential steps for using this flow to reduce compile time and demand less compute resources.
It is first of many "Getting the Basics Right" Application Notes that the Palladium-XP Product Launch Engineering (PLE) team at Cadence plans to develop. These Application Notes will enable users with benefits of learning and productivity using the self-help knowledge on Cadence Online Support at http://support.cadence.com/.
In their Application Note, Robert and Jim note that the simulation acceleration compilation with external netlists executes selective processing that does not parse or synthesize the netlist portion of the design. The netlist portion passes to the back-end compile stage where the tools stitch it together into a complete DUT along with the RTL code. It then maps the complete design to accelerator primitives. This selective processing of the netlist results in a significant reduction in the compile time by reducing the amount of code that is unnecessarily processed.
The flow requires user data files containing directives to guide the compile including information about the netlist source files, any references to objects in the netlist, and compile control directives.
This document will describe the steps required to generate a complete set of directives to ensure a successful compile and explains some of the potential issues to avoid. To access the complete Application Note, please click here: How to efficiently use large netlist files with simulation acceleration.
Sharing the Load
Palladium XP® is a verification compute server that is comprised of multiple compute resources (boards of logic domains) connected to one or more general-purpose host workstations - all of which need to be time shared as individual or multiple slots to run hardware based verification jobs. Palladium has its own job management tool called the Configuration Manager (configmgr) that allocates the requested logic resources and can even relocate jobs to alternative logic resources if it decides it is appropriate to do so.
Compute intensive workplaces often organize their available processing resources as a ‘farm' of remote servers that are shared by all users. In order to ensure fair and efficient access, IT departments will often enforce access through an automated load sharing facility. One of the most popular is Load Sharing Facility (LSF®) from IBM® Platform ComputingTM.
Robert McLellan, Architect at UK Cadence, wrote an Application Note titled How to Integrate Palladium XP and LSF. This note tells us that the Palladium verification compute server is unlike an ordinary general-purpose server -- it has a special purpose interconnect between domains and to external targets. This leads some to wonder how to integrate it effectively with their LSF general-purpose compute environment so that the Palladium can appear like just any other compute resource on their network. This How-To Application Note is the first in a series that will describe a simple way to do this.
More advanced configurations are described in subsequent How-To documents, including how to have multiple execution hosts, multiple DBEngine hosts, and even multiple Palladium compute servers; how to extract more useful statistics from the LSF queues; and how to use Palladium domain knowledge to better optimize the automatic assignment of jobs to domains.
This How-To document describes how to integrate Palladium XP with LSF assuming the simplest of configurations -- one Palladium XP compute server served by one DBEngine host. All user jobs run on the DBEngine host, but there is provision for specifying the priority of the jobs through two separate queues. Jobs can be interactive or batch. There is a brief description of how the administrator can observe the queue usage.
To access the full Application Note, please click here: How to integrate Palladium XP and LSF. Please keep visiting http://support.cadence.com/ to get your copies of these Application Notes. We will keep sharing further how-to knowledge in this series.
NOTE - You will need to use your Cadence credentials for the Cadence Online Support http://support.cadence.com/ web site to access the Application Notes.