Start Your Engines: Debugging Mixed-Signal Partitioning Issues Using the Elaborator

Cadence Spectre AMS Designer is a high-performance mixed-signal simulation system. The ability to use multiple engines and drive from a variety of platforms enables you to "rev up" your mixed-signal design verification and take the checkered flag in the race to the market. The Start Your Engines! blog series will provide you with tips and insights to help you tune your simulation performance and accelerate down the road to productivity.

Mixed-signal partitioning issues are a common occurrence in mixed-signal functional verification flows. Frequently used mixed-signal elaborator options can place users into tough predicaments, whereas electrical discipline propagation or real coercion can be too aggressive for the design configurations being simulated.

Cadence's mixed-signal solution allows for dynamic configuration combinations, with any abstraction level, at any level of the design hierarchy. With that versatility, the elaborator must take the "most conservative" approach to partitioning the design and try their best to accommodate the user's intentions to achieve the most accurate simulation results.

Performance or elaboration issues sometimes reveal this "overly conservative" partitioning behavior and requires ratcheting back to a more reasonable middle-ground. The mixed-signal elaborator is versatile enough to allow the user to implicitly control performance bottlenecks and elaboration errors without modifying the design configuration itself.

What I commonly see with mixed-signal users is the lack of knowing how to debug and resolve these tricky situations. Knowing how best to debug common partitioning-related issues and implicitly control them using common features of the mixed-signal elaborator can frequently pull you out of some tight spots.

Two common use cases, in point:

1) Using the -disres detailed option (for legitimate reasons of making sure most of the design resolves into the analog domain for accuracy)

This xrun option is commonly used to force the mixed-signal partitioning directly at the digital block boundaries, and in turn, automatic Interface Element (IE) insertion is well-defined. This option enables the most aggressive electrical discipline propagation algorithm, i.e., electrical discipline resolution starts at the analog leaf-level, propagates upwards in a bottom-up, then top-down hierarchical traversal, then stops upon encountering a hard-defined digital boundary. 

A negative effect when using this option is the fact that electrical discipline propagation can "leak" into unintended areas of the design hierarchy, i.e., RTL, verilog gate-level netlists, etc., where attempted IE insertion on complex SV constructs, etc. causes elaboration errors and/or unintended analog accuracy, which can cause simulation performance bottlenecks.

Adding the +dr_info option populates the xrun.log file with valuable debug information related to which discipline domains the ports and nets in the design belong to. Search the xrun.log file for the keyword DR_INFO to locate this debug information.

When interpreting the DR_INFO listing, it's handy to be aware of keywords used in the assignment statement telling you how and why that port or net was resolved. This helps in the overall partition debug process and allows you to confirm if certain implicit override settings worked properly.

An example xrun.log file DR_INFO listing:

Discipline resolution Pass...

         DR_INFO: Performing Bottom-up Traversal..

         DR_INFO: top.I3.a has setting discipline logic

         DR_INFO: top.I3.nz has resolved discipline logic

         DR_INFO: top.I302.a has declared discipline logic

         DR_INFO: top.net34 has resolved discipline electrical

        DR_INFO: top.I56.dr_out has setting discipline electrical

        DR_INFO: top.I4.amp_in has declared discipline electrical

• The setting keyword indicates that an elaboration option has implicitly assigned the specified discipline on that net/port prior to the discipline resolution process. The xrun option to override disciplines is called -setdiscipline. 
• The resolved keyword indicates that the normal discipline resolution process took place. That port/net was resolved to that discipline at the end of the discipline resolution process.
• The declared keyword indicates that the port/net was explicitly declared to that discipline domain either within the behavioral model port declaration or some other explicit assignment. No elaboration options can implicitly override explicitly declared ports/nets.

Users can have full control of unwanted electrical discipline "leakage" by properly applying the -setdiscipline option to the required RTL boundary scope. This essentially "blocks" all electrical discipline propagation into that RTL block, thus providing a well-defined, mixed-signal boundary partition.

2) Using the -rnm_tech option for real coercion control when mixing real number model (RNM) abstractions into your design configuration. This option is required for simulating pure digital RNM configurations by turning on the elaborator's coercion capabilities. When mixing spice content with RNM abstractions, the option is implicitly enabled by default to give the user the "most conservative" partitioning for the best accuracy.

A negative effect when using the "default" real coercion algorithm is the fact that it can aggressively propagate the real nettype deep into the RTL hierarchy itself and potentially cause elaboration errors. For instance, if the coercion boundary happens to occur on a complex SV construct, not yet supported for automatic IE insertion or encounter unnecessary performance overhead, i.e., wasting elaboration time coercing nets/ports when it's not required.

Adding the -rnm_info option populates the xrun.log file with valuable debug information related to how ports and nets were assigned to which real nettype. Search the xrun.log file for the keyword RNM_INFO to locate this debug information.

When interpreting the RNM_INFO listing, it's handy to be aware of keywords used in the assignment listing telling you how and why that port or net was resolved. This helps in the overall partition debug process and allows you to confirm if certain implicit override settings actually took place.

An example xrun.log file RNM_INFO listing:

RNM_INFO: tb.top_ana.iout is declared wrealsum with resolution 'CDS_res_wrealsum'
RNM_INFO: tb.test.op is declared wrealmax with resolution 'CDS_res_wrealmax'
RNM_INFO: tb.VDDS is declared nettype 'wreal1driver' with resolution 'CDS_res_wreal1driver'
RNM_INFO: tb.VSSS is declared nettype 'wreal1driver' with resolution 'CDS_res_wreal1driver'
RNM_INFO: tb.POWER_OK is coerced to nettype 'wrealmax' with resolution 'CDS_res_wrealmax'
RNM_INFO: tb.startReset is coerced to nettype 'wrealsum' with resolution 'CDS_res_wrealsum'

•  The coerced keyword indicates that the normal coercion process took place. That port/net was coerced to that real nettype implicitly by the elaborator.
• The declared keyword indicates that the port/net was explicitly declared to that real nettype either within the behavioral model port declaration or some other explicit assignment. No elaborator option can override explicitly declared ports/nets.

Users can implicitly control real coercion, in many ways, with the following xrun elaborator options: 

• For less aggressive coercion, use the option -rnm_coerce default with -rnm_tech. This limits coercion to a bottom-up hierarchical traversal on all type-less, wired nets/ports.
• the "default" coercion behavior is set by default with the -rnm_tech option ( -rnm_coerce detailed) and performs a bottom-up, then top-down hierarchical traversal until encountering a hard-defined SV construct or electrical boundary.
• Coercion can be turned on/off relative to a design scope.

For instance, the following example shows how to turn on coercion in instance tb.dut.cinst, and also turn off coercion on net tb.dut.cinst.dlint.d, inside the previously set 'ON' scope:

-rnm_coerce "on inst-tb.dut.cinst-"  -rnm_coerce "off net-tb.dut.cinst.dlint.d-" 

For more information on how to use all these elaborator debug options, see the Spectre AMS Designer and Xcelium Simulator Mixed-Signal User Guide.

Related Resources

For more information on Cadence circuit design products and services, visit www.cadence.com. 

About Start Your Engines

The Start Your Engines series would bring to you blog posts from several analog/mixed-signal subject matter experts on a variety of topics, such as introduction to the new features in AMS Designer, tips for enhanced working with existing features, and much more. To receive notifications about new blogs in this series, click Subscribe and submit your email ID in the Subscriptions box.

- Rick Sanborn