Presentation is loading. Please wait.

Presentation is loading. Please wait.

Bharath Kumar Poluri, Atul Ramakant Lele, Aswani Kumar Golla, Lakshmanan Balasubramanian Texas Instruments (India) Pvt. Ltd. 1 Fully automated interface.

Similar presentations


Presentation on theme: "Bharath Kumar Poluri, Atul Ramakant Lele, Aswani Kumar Golla, Lakshmanan Balasubramanian Texas Instruments (India) Pvt. Ltd. 1 Fully automated interface."— Presentation transcript:

1 Bharath Kumar Poluri, Atul Ramakant Lele, Aswani Kumar Golla, Lakshmanan Balasubramanian Texas Instruments (India) Pvt. Ltd. 1 Fully automated interface elements insertion for Digital and Analog Mixed Signal verification in multi power domain designs

2 2 Introduction For Mixed Signal designs, where there is significant number of Analog Modules (AM) interacting with each other AND/OR with Digital Modules (DM), there is a need to run Analog and Mixed Signal (AMS) co-simulation to ensure device integration and verification quality. Use of accurate Real Number models in Digital Mixed Signal Simulation (DMS) increases the accuracy of digital simulation results and reduces overall AMS co- simulation scope compared to behavioral models. AMS and DMS co-simulations inherently have electrical, and logical (boolean, real) domains. Most of the EDA tools automatically supports handling interconnection between these domains through Interface Elements(IE) if the SoC has single voltage domain. For multi voltage and multi power domain SoCs, handling these IEs is not fully automatic and require manual modification of supply information of the IEs based on the interface where it is inserted. We discuss about using design power intent, Common Power Format (CPF), from EDI™ to infer supply sensitive information for Interface Elements for completely automating the insertion of these IEs for multi voltage and multi power domain SoCs.

3 Proposed Solution(1/3) 3 CPF Synthesis Netlist Synthesis Netlist Discipline Information Discipline Information EDI ™ Power intent information captured in the form of CPF is golden for the given IP or SoC. Most of the recent flows using this information in all design stages to implement/verify the power intent which is sufficient enough to know voltage or power domain of each pin of the IP it belongs to Typical EDI™ commands used to get the pin power domains: With simple scripts post processed the power domain information obtained from EDI™ to get discipline information which simulation tool can understand foreach sig_pin [dbGet [dbGet -p1 top.insts.name $macro].instTerms.name] MSV::getInstTermPowerDomain $sig_pin foreach sig_pin [dbGet [dbGet -p1 top.insts.name $macro].instTerms.name] MSV::getInstTermPowerDomain $sig_pin

4 Proposed Solution(2/3) 4 //Macro:u_mod1_ana mod1_ana,u_mod1_ana/supply_ok_o_3P3V,u_mod1_ana_supply_ok_o_3P3V,0,PD_PD1_AON //Macro:u_mod1_ana mod1_ana,u_mod1_ana/supply_ok_o_3P3V,u_mod1_ana_supply_ok_o_3P3V,0,PD_PD1_AON Macro NameInstance Name/Macro Pin Name Net to which the pin Connected to Signal/ BusPower Domain CPF Synthesis Netlist Synthesis Netlist create_disciplinedotf.pl EDI ™ discipline_gen.tcl Power Domain Information from EDI™ //Macro:mod1_ana //Instance:u_mod1_ana -setdiscipline "INSTTERM-tb.duv.u_mod1_ana.supply_ok_o_3P3V- logicpd1" //Macro:mod1_ana //Instance:u_mod1_ana -setdiscipline "INSTTERM-tb.duv.u_mod1_ana.supply_ok_o_3P3V- logicpd1" -setdisciplineInstance Terminal Pin HierarchyPower Domain Discipline information for IRUN

5 Based on the No. of power domains in a given SoC create those many IE groups. For Example in a given SoC with 4 power domains pd1(always-on), pd2(backup), pd3(flash) and pd4(switchable) the IE group, Connect rule file and IE file names would look like as shown Update discipline information in each Connect Rule based on power domains. For using Inherited IEs update Inherit net information in each IEs based on the voltage domain that IE belongs to Proposed Solution(3/3) 5 IE GroupsConnect RuleIEs Connect_pd1CR_full_pd1E2L_full_pd1 Connect_pd2CR_full_pd2E2R_full_pd2 Connect_pd3CR_full_pd3R2L_full_pd3 Connect_pd4CR_full_pd4L2R_full_pd4 discipline logicpd1 domain discrete; enddiscipline discipline logicpd1 domain discrete; enddiscipline electrical (* integer inh_conn_prop_name="pd1"; integer inh_conn_def_value="tb.ams_pd1"; *) \pd1! ; electrical (* integer inh_conn_prop_name="avss"; integer inh_conn_def_value="tb.ams_VSS"; *) \avss! ; electrical (* integer inh_conn_prop_name="pd1"; integer inh_conn_def_value="tb.ams_pd1"; *) \pd1! ; electrical (* integer inh_conn_prop_name="avss"; integer inh_conn_def_value="tb.ams_VSS"; *) \avss! ; Ex discipline update in Connect Rule for pd1 power domain Use –amsconnrule switch and compile the above IEs along with design compilation. Place all setdisciplines in a file disciplines.f and add this file to irun command During discipline resolution, tool uses discipline information of each interface and picks up the appropriate IE

6 Usage of CPF information for IE insertion in DMS and AMS is most accurate and enabled reusability of existing power intent information provided by designer for mixed signal co-simulations The flow completely eliminated false failures because of wrong supply information which is very costly for AMS co-simulations as these simulations require very long run times Deriving discipline definition for the given SoC is one time effort and reused it across DMS(RTL, GLS), and AMS(RTL, GLS) co-simulations as these disciplines are configuration independent. The flow is implemented in two platform designs. Very minimal manual intervention for IE management for both projects Improved overall efficiency of DMS and AMS co-simulations and enabled in-time closure of all simulations by finding critical design issues The flow is very generic and can be implemented with very minimal effort in any power managed SoC for DMS and AMS co-simulation Results 6


Download ppt "Bharath Kumar Poluri, Atul Ramakant Lele, Aswani Kumar Golla, Lakshmanan Balasubramanian Texas Instruments (India) Pvt. Ltd. 1 Fully automated interface."

Similar presentations


Ads by Google