UVM with AMS: Best practice for handling OOMR DUT probes with different net types

[Paul Miller]

Hello all. 

I am working on developing a set of best practices for handling OOMR probing of DUT signals. In particular, when using different device configurations in a mixed-signal context. 

The DUT I'm working on is a sensor, comprising signal-conditioning blocks, and ADC, a medium-to-low complexity digital core, and some other peripheral blocks such as a temp sensor, NVM, etc. 

We currently have 2 closely related DV teams.

1.  "Analog Mixed-signal" (AMSDV), using the variety of config views mentioned below; focusing on targeted/directed tests for analog functionality, looking for unexpected circuit interactions amongst other things. 
2. "Digital Mixed-signal" (DMSDV) , using solely real-number-models for the analog blocks; focusing on digital state-machine verification and functional coverage, using constrained random tests 

Because of the nature of our DUT, top-level analog sims are prohibitively CPU. As such, I use a combination of configuration views that specifically target analog functionality as Spectre for a given MSDV test, replacing the rest of the Mixed-mode circuits with real-number models. Using this approach, we've reached tolerable simulation expense. 

We are sharing a SystemVerilog UVM Mixed-signal environment in order to share checkers, monitors, stimulus, etc. across the teams and reduce rework and all of the other reasons for doing so.

With this method, our teams run into issues with OOMR references for signals inside the DUT needed for monitors and checkers probing signals. In different DUT configurations, these signals end up being a variety of non-compatible data types (below) which ends up injecting undesirable connect modules into sensitive analog nets and corrupting simulation results or resulting in elaboration failures.  In addition to the elaboration failures, these sims may result in false passes, or difficult to debug fails. 

• Logic
• Real
• EENET
• electrical 
• etc. 

I've looked into several methods for working around this issue

1. ifdefs to change the signal type we are tying signals into inside interfaces, for example
   `ifdef DMS
        real sig1;  
        assign sig1 = OOMR.sig1
   `else //MSDV
       @(event) sig1 = $cgav(OOMR.sig1 ...) ///shortened for readability  
   `endif 
   1. We do not like this approach because it is difficult to maintain for multiple config views,
   2. if you miss a signal, it may just insert a connect module and corrupt your sim in a difficult to debug manner,
   3. It is exceptionally cumbersome to use for "continuous" signal monitors, as in a LDO output checked so never goes out of a given tolerance. 
   4. This is not scalable 
   5. ifdefs can result in "hidden" compile and elaboration failures when blocks change with a large team
2. expansive IE cards to handle all signals being probed:
   1. Cumbersome to maintain for multiple config views
   2. Because of the handling of IE card statements, ends up inserting connect modules in undesirable locations and corrupting simulation results 
   3. Not scalable 
3. Effectively creating a custom connect module (VAMS module) using $real_net_alias and $analog_node_alias to alias the nodes to nets internal to the custom CM, and then converting the signals based upon which net type is used. This is my favorite so far but adds some additional complications.
   1. This is fairly easy to automate the insertion and creation of these custom CMs 
   2. It handles real and electrical nets, which can be converted to other event-based data types 
   3. allows the user to directly control the sampling tolerances for analog nets through the instantiation of the mod
   4. but it only handles "nets" of electrical or real data type. if the user attempts to assign a real "variable" it will result in an elaboration error so RNM models must be modified to deal with this restriction
   5. It may increase license utilization in DMS simulations 
   6. it may not be supported across multiple tools.

How do other teams/companies/engineers handle this issue? 

 

My ideal would be a method which allow the user to get values that may be of any arbitrary data type in a given simulation without corrupting a sensitive analog signal. This could be solved by the IE being inserted on the "environment" side, rather than on the DUT side, which is the exact opposite of how connect modules are currently inserted in our simulator. 

[tfitz]

Hi Paul,

Please consider joining the UVM-AMS Working Group.

Tom Fitzpatrick
Chair, UVM-AMS Working Group

[Paul Miller]

Thanks, I just did so.