Never miss a story from Analog/Custom Design. Subscribe for in-depth analysis and articles.
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
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'
Users can implicitly control real coercion, in many ways, with the following xrun elaborator options:
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.
Spectre AMS Designer and Xcelium Simulator Mixed-Signal User Guide
Spectre AMS Designer Product Page
One-Stop Knowledge Resource for Mixed-Signal Verification
For more information on Cadence circuit design products and services, visit www.cadence.com.
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