Analog IP Integration in SoC: Challenges and Solutions

Abstract :

In not-so-distant past [2], less than 20 percent of high-end digital devices had any significant amount of analog/mixed-signal (AMS) content; by comparison, in the case of design starts in 2007, more than 80 percent of devices contain relatively large amounts of AMS. Today’s applications need digital processing coupled with analog to digital converters (ADC), digital to analog converters (DAC), Phased Locked Loop (PLL) and other analog IP’s.

Analog circuits are sensitive to layout, matching, proximity and demand attention to interface details such as signal swing, zero level, and drive impedance. This increase in analog content in System on Chip (SoC) and complexity of analog IP brings in new challenges slowing the progress towards fully functional first time right device. Several full chip design respins occur due to issues with analog IP. Difficulty with analog IP integration or reuse is widely recognized fact and there have been several discussions on this topic in various technical forums and conferences [2]. However little methodology work is done for successful analog IP integration/reuse.

This paper introduces detailed methodology guidelines for successful analog IP integration in SoC. The guidelines described in this paper are based on thorough root cause analysis of real design issues related to analog IP from several SoC designs. The knowhow of issues prior to design tapeout and ensuring compliance to guidelines listed in this paper had been successful in significantly reducing design re-spins and getting closer to fully functional first time right device.

This paper starts with introduction section which describes general description of analog IP reuse concerns. It is interesting and informative to look at some of the Analog IP challenges that need to be tackled by SoC integrator.

The second part of this paper describes methodology guidelines. This section lists major gaps associated with analog IP use in SoC, describes problems with real world examples

related to these gaps and provides recommendations/best practices based on root cause analysis of these issues for successful analog IP integration.

Last section concludes this presentation highlighting the benefits of methodology guidelines proposed in this paper

I. INTRODUCTION

IP reuse [3] from previous design or 3rd party vendor is a need in order to meet constraint design cycle time. However Analog IP reuse may not be straight forward due to changes in parameters that results in design issues. Some of these details are listed below:

• Technology node change/migration: This brings in new set of challenges. Same analog IP may necessarily not work in lower technology node due to following issues
• Voltage scaling impacting the signal to noise ratio and signal propagation time.
• Interconnect pitch scaling. This results in changes in parasitics of interconnect and resulting signal integrity (SI) effects which can be a critical problem when integrating analog IP. For instance performance of Low Noise Amplifier (LNA) can be extremely sensitive to the RLC parasitics on the input interconnect
• Device performance changes impacting the interface noise. A change in clock frequency may lead to different noise coupling issues on the analog IP
• Requirement change: Specification change even at the same technology node necessitates design changes impacting the functionality bringing in issues with design resuse to meet exactly same design performance requirements.
• Foundry change: It is also not very uncommon to observe different analog behavior for the same analog IP at a common technology node due to difference in process technology of the foundries.
• Changes in usage scenario with integration in different SoC: PLL integrated in wireless application with 100 MHz digital clock frequency of microcontroller may not behave the same when compared with wireline application at a different frequency due to different noise environment, footprint constraints or different mode of PLL operation.
• Changes in EDA tools
• Different EDA tools may have different device model leading to different simulation results.
• Another common problem with EDA tools or design flow is inability to accurately check consistency between behavior model and schematic. The simulation results may indicate a pass with the old model which may not be true representation of actual (modified) IP leading to silicon failure.

Some of these changes result in redesign of schematic and layout views to meet different requirements of timing, dynamic range, load, gain, power, parasitic noise concerns which impacts overall design cycle time.

Integrating an analog system on chip is a complex process and demands specific attention to minimize issues.

Figure 1. Integrating an analog system on a chip[1]

II. METHODOLOGY GUIDELINES

Analog IP is provided as hard IP in the form of GDSII layout block which are fixed in size, tied to a particular foundry, process and are often difficult to integrate. The specific characteristics of analog design make the development of flexible analog IP modules for reuse a much more difficult task.

Analog IP comes with common integration issues associated with digital IP plus a set of issues unique to analog. The table1. below depicts categorization of some of the analog IP issues found in SoC’s resulting in silicon respins:

Table 1. Gaps in Analog IP integration in SoC

This section lists problems based on above gaps and describes issues in detail with real silicon failure scenarios. It also suggests methodology tips based on root cause analysis to prevent reoccurrence of these issues.

Gap 1: Test Chip Setup

Problem#1: Test scenario on test chip sometimes is not complete and may not represent actual setup/results as in SoC.

For instance one of the SoC design used integrated PHY and controller IP whereas the setup for validation had two separate testchips for controller and PHY. The scenario/interoperability of PHY with controller was not tested in testchip. As a result when silicon failure was observed on actual SoC device due to interface timing issue between PHY and controller IP; it could not be detected or even reproduced on test chip. This failure required different diagnostic approaches with multiple expensive and time consuming FIB’s to eventually detect the root cause and prove the fix which otherwise could have been detected early and avoided with similar testchip setup.

In another silicon failure one SoC had 4 PLL where test chip successfully verified PLL as functional using only one PLL. The sensitivity (foundry dependent) could not be replicated or checked in any way on the test chip.

Problem#2: Tester setup used for testchip may differ and give different results.

For example tester used for test chip can be synchronous whereas a different (asynchronous) tester is used to validate actual device. Testchip results can be clean while actual silicon with different tester may fail.

Recommendations:

SoC engineer should ensure correlation of test chip results replicate similar scenario as actual production silicon to support early and complete validation on testchip thereby minimizing surprises with actual production device

Gap 2: Inbuilt functionality debug, de-risk option

Problem#1: Incomplete debug capability in SoC can result in difficulty in finding the root cause.

Flexibility to toggle and observe analog IP internal signals is usually missing when IP is integrated in SoC.

Recommendations:

Designer can add inbuilt test within SoC such as using processor to ‘Load’ and ‘Execute’ instruction from RAM and compare the final result with predefined pass signature.

SoC integrator can also look at option to provide debug capabilities with use of JTAG tap controller which allows access to critical IO’s for strobing and observability, thereby minimizing overall debug time.

Problem#2: It is impossible to validate device functionality if there is no stable clock.

Almost all the SoC’s today have some PLL built into the chip to provide high frequency clock within the chip. PLL sometime is not stable and without stable clock it is difficult to validate the device functionality as working.

Recommendations:

SoC engineer should check for de-risk option to add test to validate critical functionality such as PLL.

Design engineer must look at bypass option which allows to bypass the PLL and supply stable external clock. This would enable driving clock directly from the pad for validation of basic on chip functionality and identify issue due to specific PLL mode not generating correct clock in non-bypass mode.

Gap 3: IP Interface Verification within SoC.

Problem#1: Incomplete methodology to validate IP interface can sometimes result in missing signals for connection or sometimes connecting wrong signals at interface

One of the SoC’s had silicon failure when two important control signals including reset signal for analog IP was missed from connectivity list. Existing verification methodology using force-sense only verified the partial signal connectivity list leading to device failure.

Similar issue was also found with another device where one of the critical signals was swapped and could not be detected with this verification methodology of point to point signal connectivity check.

If the complete functionality of IP is also not modeled in behavioral model these functional fail due to missing connection or swap of signals are also missed at top level

Recommendations:

Designer must ensure interface connectivity of IP is checked with proper test environment. Using force and sense (point to point signal connectivity)verification process on signal is not robust and has verification gaps as there is possibility that interpretation of specification is wrong both by RTL and verification engineer. Instead IP integrator should request for delivery of assertion based checker which not only checks the connectivity of interface signals but also validates relationship between signals useful to capture illegal interface protocol issues.

Gap 4: Review process between IP and SoC team.

Problem#1: Incomplete common review process is one of the reasons for finding issues late after SoC integration since the scenario of standalone IP verification is different as compared to verification after integration of analog IP in SoC.

Sometimes information related to analog IP such as documentation, views, abstracts are not adequate for integration in SoC. Review signoff process by both parties can minimize issues due to assumptions taken by SoC integrator in case if some information is missing or relying to much on simulation model results. For instance in one of the device ‘Power Reset Clock Manager module’ state machine failed to release the reset signal due to illegal sequence of control signal leading to silicon failure. This illegal sequence leading to silicon fail was neither documented in specification nor modeled correctly in simulation model. A common checklist review could have potentially avoided this issue.

Recommendations:

A detailed common review process between IP team for all complex analog IP’s and SoC team would help identify some of these potential problems.

Analog IP should be verified standalone in functional and test mode by IP team and also by SoC team after integration.

Review process should define the signoff criteria: Simulations results should be reviewed thoroughly; All coverage goals of analog-digital mixed models should be met.Verification plan including section on analog interface has to be signed off by analog IP designer. Specs should highlight forbidden/illegal conditions. Any discrepancy found during review related to documented spec should mean specification update of that module to minimize reoccurrence of the issue.

Gap 5: Analog IP simulation model.

Problem#1: Many times reasons for device fail due to analog IP is because of mismatch between behavioral model (HDL) and schematic (spice).

Simulation passes but silicon fails with incorrect model used for simulation. The fact that there is no industry tool available from EDA company’s to validate equivalence between simulation model versus actual analog IP makes early identification of problem more difficult.

Recommendations:

Behavioral Model of an analog module should always match 100% of the time with what silicon will do. Model should not be compromised when a bug is being fixed in design to reduce re-verification effort.

Problem#2: Another reason for device fail due to analog IP is because of inherent limitation of available analog models.

Typical verification of analog output involves conversion to digital signal i.e. ‘0’ or ‘1’ by simulation model depending on threshold voltage level. Checker or BFM will capture the digital value and test pass/fail will be declared as per value captured.This process of verification has gaps:

• There is no closed loop integrity check done at SoC level because models do not have the analog output (Real number signal).
• Digital outputs (corresponding to analog signal) does not represent all the variations of the control signals.
• Models do not have capability to check illegal/forbidden control signal sequence.
• There is no voltage modeling hence (typically voltage comparators behavior change as per the control signals) exact behaviour cannot be caught.

Recommendations:

Steps should be taken to improve analog behavioural modelling for overcoming some of the above shortcomings with current approach:

• HDL model has to be equivalence checked with Spice model
• New Specman feature can be used which handles the real number modeling for analog signals.
• Output from Spice (analog mixed simulation) and HDL model has to be compared with the same test input for vector.
• All the Coverage goals have to be met for the Analog and digital mixed HDL models like we do for pure digital IP’s.
• Models have to be power aware even for analog portion and power aware model can be used at RTL simulation also.
• Assertions/checkers has to be embedded in the model when there is illegal sequencing to analog portion of the model.
• There must be exhaustive top level verification plan dedicated to verifying the analog interface and has to be signed off by analog IP designer.
• Specs should highlight forbidden conditions which might cause issues (race condition) in analog part of the IP.

Besides the above points Analog Models deliverables to SoC team should also include complete set of critical Functional and test mode cases with a method to clearly produce the "status" of the analog module in simulation. The simulation model should have capability to indicate which mode the module is in, what are internal Voltage levels, functional performance levels, and power levels. Current approach of capturing information (simulation finish) in the module register settings as defined in the spec is not sufficient for SOC design engineer to confirm if module is working correctly, and to confirm module has right setting or is controllable or observable for its digital and analog "state".

Problem#3: Using analog-mixed simulation at SoC can be time consuming.

Recommendations:

Add option to control modes in behavioural models:

• Fast model without detailed analog modeling.
• Slow model with detailed analog modeling.
• Power management on with detailed power, voltage, voltage level aware analog model.
• Power management off with normal analog functional behaviour model
• Analog mode on model converts analog signal on IP top.
• Analog mode off model converts analog signal to digital signal depending on threshold on IP top.

The accuracy of model should also be checked with test chip result or past silicon; there has been situation where interface noise from test chip was ~3 times higher than that predicted by models. The data available from test chip was used to correct the accuracy of model before actual design tapeout.

Problem#4: Sometimes inaccurate timing model for analog IP can lead to misleading results resulting in eventual device failure

In one of the SoC missing STA constraints due to incomplete information/knowledge on PHY vital model timing annotation methodology caused design failure:

PHY Synopsys library timing arcs were modeled with respect to pin ‘DUMMY1’, which is a tie-off in layout. The .lib use model in simulation requires a clock definition on DUMMY1 or short the output clock of PHY IP with DUMMY1 input pin. In the absence of this definition PHY timing arcs will not be timed in functional mode and can give silicon failure even though the simulation may pass.

Recommendations:

IP timing models should be checked against integration specification before use in Chip timing closure and signed off by IP owner.

Problem #5: Test pattern release may not match corresponding physical database. This may results in long debug time impacting schedule when test patterns fail as netist/sdf do not match due to multiple versions of same analog IP.

Recommendations:

Minimize schedule delay, Tester time due to issues/ database mismatch with analog IP DFT model release.

Integration specification should include release summary, model usage description along with limitation if any.

Gap 6: CAD tools and design flow

Apart from improving test methodology process, some work should also be done in close cooperation with EDA vendor to improve the Design flow methodology:

The flow must be constantly improved to comprehend the issues associated with analog IP integration and bridge the gap between analog and digital world thereby reducing issues associated with mixed simulation after integration of analog IP in SoC.

In past, Infineon design flow used separate analog and digital simulation environment: Modelsim/Questa for digital simulation and Advance MS for mixed-signal simulation. However the recent Infineon design flow is expected to have common frame work for mixed signal, digital-analog simulation.

The merged flow supports all analog mixed signal (AMS) modeling languages: VHDL-AMS, Verilog-AMS. The merged flow makes environment more user friendly with one common location of sources/models for the overall flow and one set of simulator initialization (single. ini) file for Questa and ADMS.

Acknowledgement: This design flow improvement is combined effort of following IFX Munich, Bangalore Design Flow teams: Thomas H, Abhijit H, Manfred T, Symbian A

III. CONCLUSIONS

This paper is an attempt to list methodology guidelines which supports easy reuse and integration of AMS content in digital domain.

Lessons learned from silicon failure were used to define and develop improvements in the areas existing verification techniques, enhancement of analog models, working with EDA vendor for tools and design flow improvements to minimize overall issues related to analog IP reuse/integration in SoC. This initiative with focus on improving verification methodology of analog IP in SoC has been successful in significantly improving the design productivity; evident from reduced issues after tapeout.

REFERENCES

[1] David Chiapinni, Massimo Vanzi, Navraj Nandra, “The Good? The Bad? The Ugly? IP Perspectives from Vendor to SoC Designer” in IP07

[2] EDA Tech Forum, Bangalore 2008. Presentation by Mentor.

[3] Raminderpal Singh, “Analog IP re-use: concerns for digitally-oriented SoC designers” in EETimes 2002

[4] Zlieying Li, Li Luo, Jiren Yuan, “A Study on Analog IP Blocks for Mixed-Signal SoC” in ASIC, 2003. Proceedings.

BIOGRAPHY

Pankaj Singh completed his bachelors in electronics from REC Bhopal in 1993; Master’s in electrical engineering from USF, Florida in 1997 and an MBA from SMU, Dallas in 2001. He has 15 years of industry experience. In the past he has worked in various design lead roles such as IP development Manager, functional verification Manager, WIMAX SoC Design Manager. Currently he is working with Infineon India as Sr. Manager, Design Flow Department Head.