Analog Mixed-Signal Verification at SOC level: A practical approach for the use of Verilog-AMS vs. SPICE views

Transcription

1 Analog Mixed-Signal Verification at SOC level: A practical approach for the use of Verilog-AMS vs. SPICE views Gautham S Harinarayan, Senior Design Engineer (gautham@freescale.com) Nitin Pant, Lead Design Engineer (nitinpant@freescale.com) Manmohan Rana, Prinicipal Staff Design Engineer (manmohan.rana@freescale.com) Automotive MCU, Freescale Semiconductor, Noida, India Abstract In the world of complex mixed signal micro-processors, Analog Mixed Signal (AMS) verification has become an extremely important task. To achieve maximum electrical coverage without compromising the quality of verification, an intelligent approach is needed while picking model definitions of the analog blocks. This paper statistically talks about choosing Verilog-AMS or SPICE views of the analog blocks for verification at SOC level by making real time application based case studies. These case studies can be broadly divided in to groups such as Power Management, Data Converters, Clocking and Peripherals. We also describe several defects caught through pre-silicon SOC AMS simulations. We conclude with a quantification of the differences in the average runtime between Verilog- AMS and SPICE. Keywords Verilog; Verilog-A; Verilog-AMS; SPICE; AMS; Analog Mixed Signal; Mixed-Mode Verification; Debug; Power Management; Data Converters; Clocking; DDR; LCD. I. INTRODUCTION The System-on-Chips (SOCs) produced today provide a high level of functionality, driving a wide range of applications, while becoming more and more cost effective. This means that the complexity of the SOC too is reaching an all time high. Dozens of Analog IPs and Digital IPs are integrated into the same SOC. It contains multiple voltage domains that support several modes like Standby, Low power, Reduced Clock Mode, etc that necessitate a dedicated on-chip Power Management Controller. Additionally there are several peripheral IPs that are needed to interface with real world signals and external ICs. These include Data Converters, Clock sources, Phase Locked-Loops (PLLs), Double Data Rate (DDR) interfaces, Liquid Crystal Displays (LCD) controllers and other High Speed Interfaces like Universal Serial Bus (USB), PCIe, MIPI, etc. Finally memory IPs like RAM, ROM and NVM also form an important part of SOCs. II. SOC LEVEL ANALOG MIXED-MODE VERIFICATION A. Need for SOC Level Analog Mixed-Mode Verification With increasing level of complexity the scope for defects that can occur also increases manifold. An IP by itself may work as expected and pass all specification checks. But after being integrated into the SOC it has to interface with other IPs and logic. Some circuitry may even be present off-chip, and may or may not adhere to protocol standards. To achieve first pass success of such complex SOCs in silicon, a robust pre-silicon verification methodology needs to be implemented. A simple Verilog behavioral model of Analog IPs, will not be able to replicate any of the true analog behaviors of these circuits. This necessitates the need for Analog Mixed-mode Simulations (AMS) that target the various features and modes being supported. These simulations use a mix of SPICE and/or Verilog-A/AMS views of Analog IPs along with Verilog views of the Digital IPs. 1

2 B. Challenges faced in running SOC Level Analog Mixed-Mode Simulations In addition many of these simulations also need to be run across process and temperature corners. This results in an AMS simulation count that runs into the hundreds. Defining and implementing these simulations accurately is a complex task. Moreover simulating all of them is quite computationally intensive. Thus it is important to weigh the pros and cons of using a Verilog/Verilog-AMS view with respect to a SPICE view for all the Analog blocks and IPs within a SOC. This process needs to be carefully repeated for different AMS simulations, each targeting a different type of check. Verilog/Verilog-AMS is a behavioral abstraction of the circuit that sacrifices accuracy for the sake of run time, while SPICE does exactly the opposite. In this paper, we describe issues caught through pre-silicon SOC level AMS simulations, while comparatively analyzing the usage of both the views for various types of targeted checks for the following functional blocks: [i] Power Management [ii] Data Convertors [iii] Clocking Blocks Figure 1 Overview of a complex Mixed Signal SOC and Testbench as used in a SOC-AMS setup [iv] Peripherals like DDR sub-system and LCD Controller III. POWER MANAGEMENT VERIFICATION A. Voltage Regulator Startup Usually, the BGR is fairly stable and fairly well characterized, though every characteristic of the BGR circuit cannot be modeled in Verilog-AMS (VAMS). These characteristics include metastability of comparators, comparator offset, start-up behavior and start-up time, etc. Hence it can be modeled in VAMS to a certain extent. At the same time, due to its inherent behavior of attaining a fixed DC operating point after the initial settling period, a SPICE view of the same would also operate pretty fast, though the SPICE view would be inherently a little slower compared to using a VAMS view. The gain in accuracy by using a SPICE view of the BGR in SOC- AMS patterns checking PMC startup, will be well worth the minimal hit to run-time. If the VAMS view of the BGR is taken for crucial PMC power-up patterns it could lead to big surprises later on due to loss of coverage. On the other hand a SOC-AMS pattern specific to Phase Locked Loops (PLLs), would be somewhat unconcerned with the true behavior of the BGR. In such a case the VAMS view would suffice. 2

3 Figure 2 SOC-AMS simulation snapshot showing the profile of Voltage Regulator Startup B. Low Power State Machine The entire behavior of mode transition is controlled by the low power state machine, which works in sync with the various analog IPs to execute the mode transitions. The low power state machine by itself is a digital state machine, which is basically synthesized logic. It is entirely possible to take a Verilog/VAMS view of this state machine without losing accuracy. Hence it is recommended to use the Verilog/VAMS view of the state machine on account of the gain in simulation speed achieved. Figure 3 A typical sequence of events during mode transition in a SOC with multiple power domains and regulators. This figure shows transition from a full power RUN mode to a Low Power Mode. The low power state machine is responsible for executing the mode transitions C. Mode Transition & Low Power Configuration for Analog Blocks Modeling the analog blocks in VAMS, will also involve modeling the intricate details of those IPs such as: exactly when it turns ON or OFF, how much power it consumes, leakage, handshaking between digital state machine and the analog IP during mode transition, etc. Handshaking would inherently contain analog delay. Inadequate modeling of this behavior can lead to sampling error. Considering that the average SOC today contains dozens of analog IPs and multiple power domains, it would be troublesome to accurately to model the Low Power configuration of all those blocks. Additionally, the re-entry to Run Mode is essentially the PMC powering-up, and hence it is important to maintain accuracy of the simulation. Thus we are left with using the SPICE view for the analog blocks, which would be very accurate but slow. 3

4 Figure 4, shows a defect related to mode transition that was caught using SOC-AMS simulations. A co-relation was observed between the Regulator discharge level and wake-up event. In this case, the wake-up occurred when the regulator output had discharged to 600mV. The regulator initially responds slowly, only to later cause an abrupt and massive inrush condition. This causes the 1.5V input high voltage supply to fall as low as 1.17V. This severe inrush condition wasn t seen at other discharge levels. It needed a design fix in the PMC IP. This defect was identified only because the PMC was taken in SPICE in the SOC-AMS simulations that were run for verifying for mode transitions. Figure 4 A defect related to mode transition that was caught using SOC-AMS simulations. The regulator discharge level during mode transition and wake-up event was found to have a co-relation. This defect was identified only because the PMC was taken in SPICE in the SOC-AMS simulations that were run D. Loading Impact Loading is brought about by the current sipped by the SOC through the regulator. Modeling the impact that loading has on the regulator, requires accurate modeling of the current itself. The loading impact itself will depend on the load and line regulation of the regulator. Loading on the regulator plays a role in each of the phases, namely power-up, run mode, low power mode: Power-up is more or less static, with little clock activity. Major contribution is due to leakage at this phase, with very little activity in logic circuits. In Run Mode, clock activity dependent circuits are a major contributor to loading. This is in addition to loading due to leakage. In each of the scenarios, the power regulator sees a different type of current load transition. The regulator output voltage would show overshoots and undershoots and takes some amount of time to settle to their final values. These behaviors too would vary across scenarios. An example of line regulation is the case of non-monotonic power supply to the SOC. A use case where this is experienced is when the power generated by a solar panel is given as supply to the SOC. As the Sun rises gradually the voltage output of the panel increases gradually (but non-monotonically) over the period of minutes/hours. Any abrupt changes in the current load during such a non-monotonic supply ramp up can lead to low voltage conditions that cause a RESET in the chip. The load regulation, line regulation and the settling time of a regulator are all intrinsically analogish in nature. Modeling them in VAMS would be a difficult task, that even if done would prove to be very inaccurate. Figure 5, shows a defect that was observed during exit from the lowest power mode of the SOC. The asynchronous wake-up event triggers the Oscillator. But the Low Power regulator isn t able to handle the transient load it faces, causing the regulated core voltage to undershoot drastically. This creates a system RESET and is a cause of failure in the Low power mode exit. 4

5 Figure 5 Transient loads on regulated supplies may cause a system level impact; especially in multi regulator SOCs. The vulnerability of the system under such conditions can be accurately simulated using SPICE views of the related blocks E. Current Consumption Checks While the SOC is powered by external source, the logic cells and blocks drain some amount of current from the supply. This measure of current depends on the activity or the power mode of the operation. For e.g., during boot up, only few logic cells are active while rest of the blocks are under RESET state, hence the current sipped is low. Similarly, in a low power mode a majority of the blocks inside SOC are powered down or clock gated or both, then current drained is very less. However, during the full performance mode where most of the logic cells are clocking at maximum allowed frequency, the current drawn could be very high depending upon the amount of logic gates and blocks active, temperature and operating voltage. During the verification, current checkers are necessary to keep an eye on the total current drawn on the supply. Such verification is helpful to determine the current carrying capacity of the external supply source while SOC is running. Standard cells have a steady variation of current consumption across voltage, process and temperature. Therefore it is easier to model them in VAMS and due to the large number of standard cell logic in SOC. VAMS models would give an added advantage of speed during simulations with fairly accurate current estimation. On the other hand, Analog Blocks such as Voltage Regulator, Data Converters, Analog Comparators and Oscillators have unpredictable variations across corners and hence need SPICE view for accurate current estimation. The external board components also need to be modeled realistically, and Verilog-AMS satisfies this requirement quite well. Figure 6 describes this graphically. Figure 6 Current estimation checks for Analog IPs need to use SPICE views, while for Digital IPs it can be modeled using Verilog- AMS. The external board components also need to be modeled realistically, and Verilog-AMS satisfies this requirement quite well 5

6 F. Summary We summarize the points related to Power Management Verification discussed above, in Figure 7. Figure 7 Summary of SPICE and Verilog-AMS view comparison for the targeted checks within the Power Management category IV. DATA CONVERTOR VERIFICATION A. Data Convertor Integration and Basic Contention Checks Data converters are made up of an Analog hard-block along with a digital configuration block. The signal path involving Data Converters in a SOC-AMS setup also include the Input/Output PADs (I/Os), and a set of Analog Multiplexers through which the analog signals are routed from OR to the external world. The digital configuration block of Data Convertor, is synthesized logic and can be safely taken in Verilog/VAMS without loss in accuracy. For a basic sanity test from an integration point of view, the PADs can be taken in VAMS view, which would also give a high level of accuracy. This would also permit modeling of basic contention like weak/strong pull-up/pull-down, since strength of drivers can be modeled accurately using VAMS. Similarly since the targeted check is simply the integration and conversion check of slow varying analog signals, the ADC analog block too can be in VAMS. VAMS views can also be taken in AMS simulations where the Data Convertor is just one the components of the sub-system being verified. For example the output voltage of a Digital to Analog Convertor (DAC) is used to verify other analog blocks such as voltage comparators (Figure 8). Here the whole subsystem is under verification and analog voltages can be driven based on a digital look up table modeled inside DAC VAMS view. This will save overall simulation time of subsystem under verification and improve the coverage as well. Figure 8 VAMS views can also be taken in AMS simulations where the Data Convertor is just one the components of the sub-system being verified 6

7 B. Data Convertor Dynamic Functionality, Complex Contention and SNR Checks Modeling of static & dynamic parameters of data converters in VAMS view will not be feasible. These parameters include comparator offset, integrated non-linearity (INL), differential non-linearity (DNL), Signal to Noise Ratio (SNR), Signal to Noise and Distortion Ratio (SNDR), Total Harmonic Distortion (THD), etc. These parameters can be accurately simulated only when the Data Convertor analog block is in SPICE. There is also the case where is the input is varying rapidly, and the conversion can no longer be classified as a static one. This to needs a SPICE view of the ADC. Other behaviors which a VAMS view will be unable to cover include complex cases that involve dynamic behaviors of Transmission Gates in the signal path on account of the varying nature of their ON resistance; parallel calibrations and parallel conversions of multiple ADCs that share the same reference, etc. Such cases can be found in pre-silicon AMS simulations only when all the blocks along the entire electrical path of the analog signal is in SPICE view. This path typically includes the PADs, analog multiplexers and the data convertor itself; all of which need to be taken in SPICE. Figure 9A A sinusoidal input is given to the ADC for conversion and is converted to a set of digitized data. In this case the input is constantly and rapidly changing, requiring the SPICE view of the ADC Figure 9B Reconstructed sine wave obtained from the digitized data output from a SOC level simulation with the ADC in SPICE Figure 9C Frequency spectrum plot for SNR/THD measurement 7

8 C. Real Time Application Use-cases A special case is that of several different IPs sharing an analog path. For e.g., the same ADC input channel may receive inputs from an analog pad as well as from a Temperature sensor output (Figure 10). The two different analog signal sources are controlled by the use of Transmission Gates, so as to not let them enter a state of contention. These TGs themselves are controlled by certain digital logic controlled through register programming. To catch such cases where contention of analog signals is possible it is essential to have all the IPs generating these analog signals in SPICE, the only tradeoff being the simulation run time. Figure 10 An example of real time application use-cases: where the ADC receives inputs from multiple input sources, an external source routed through an I/O pad and a Temperature sensor in this case D. Summary We summarize the points related to Data Convertor Verification discussed above, in Figure 11. Figure 11 Summary of SPICE and Verilog-AMS view comparison for the targeted checks within the Data Convertor category V. VERIFICATION OF CLOCKING MODULES Mixed mode simulations are limited in their speed/time-step-size by the fastest switching electrical node in the design. As soon as a clock source taken in SPICE view starts toggling, the step-size taken for the entire design become extremely small. This considerably decreases the speed of the simulation. The faster the clock source more is the time needed for the simulation to complete. A. RC Oscillators To ensure proper AMS verification from a basic integration and functionality perspective a behavioral view of the RC oscillator will suffice. This will also ensure no hit to runtime. 8

9 On the other hand there can be certain corner cases which a behavioral view will not be able to cover. For e.g., during a very slow power ramp up, when RC Oscillator supply is marginally OK and its internal references are still building up. Say the reset on the RC Oscillator is lifted when the BGR is still not stable enough. In such a case the oscillator is likely to provide a bad clock output, leading to corruption of the digital state machine. Also during power mode transitions, system clock switches frequently from IRC to another clock source or vice versa. It is essential to keep check of the oscillator behavior, for e.g. the clock may start/stop with glitches, sudden turn ON/OFF of clock may show loading impact on weak on chip regulators (Figure 12). Such cases can be best covered with SPICE view of IRC in AMS simulations. Figure 12 An example of a corner case, which a behavioral view of the IRC will not be able to cover B. Crystal Oscillator Similar to the case of RC Oscillators, a SPICE view of XOSC components will drastically slow down simulation speed once the clock starts toggling. Hence a behavioral model of XOSC is suggested for the vast majority of test cases, where XOSC is not the focus of the test. But the behavioral model will not be able to cover certain corner cases. For e.g., a system RESET on SoC can reset the configurations of XOSC asynchronously, such configurations include Gain Control bits of the amplifier. This sudden change in AGC gain may reflect as a glitch on the XOSC output (Figure 13), leading to corruption in several other digital blocks. Thus it is crucial to verify the electrical behavior of the XOSC by using the SPICE view to check for certain destructive cases. The crystal itself can be described in terms of R1,L1,C1 and C0, in either VAMS or SPICE. The amplifier and AGC circuits are sensitive to various types of noise and must be taken in SPICE. The digital state machine is a counter that counts pulses and can be taken in Verilog. Such a simulation will once again have a long runtime, but it will have high accuracy and help avoid potential design bugs. Figure 13 The crystal oscillator is mainly sensitive to loop gain and any change in gain settings may lead to wrong output clock behavior. SPICE netlist will show the true behavior of the oscillator under such cases 9

10 C. Phase Locked Loops (PLLs) For verifying a multiple PLL sub-system, we need to run several different test cases, each of which focus on the verification of a single PLL-single reference clock source combination. For e.g., in a sub-system with 3 PLLs and 2 possible clock sources, we need 6 different test cases, with each focusing on one combination at one time (Figure 14). In each such test case, the particular Analog block of the PLL under consideration and its respective reference clock source are taken in SPICE. The Digital block of that PLL is simply a state machine and can be taken in VAMS. Additionally, the rest of the two PLLs which are not the focus of this test case can be taken in VAMS, since they will be exhaustively verified in one of the other test cases. These specific single PLL-single reference clock source patterns can be used to target checks like the behavior of the PLL to a reset event or loss of reference clock, and observing the corresponding effect on PLL lock. Figure 14 A hybrid approach must be adopted here to avoid unnecessarily huge simulation run times D. Summary We summarize the points related to verification of Clocking Modules discussed above, in Figure 15. Figure 15 Summary of SPICE and Verilog-AMS view comparison for the targeted checks within the Clocking Module category VI. DDR SUB-SYSTEM VERIFICATION The DDR subsystem comprises of the Processors, the on-chip RAM, the DDR controller, several groups of I/O pads and finally the off-chip DDR memory itself. These groups of pads perform different functions like data transmission and addressing; performing ZQ calibration; sending out a clock to the DDR memory; sending out control information (RESET, Clock enable); control bits to tell the DDR memory how to decode the Address bits, whether as row or column addresses. In any High Speed interface, the important components would be a transceiver, a clock source, a clock recovery circuit, proper pull-ups and pull-downs to define the reset states and on-die-terminations to ensure proper impedance matching. A couple of points different about the DDR sub-system is that it doesn t have a separate analog PHY, instead these functionalities are embedded in the pads themselves. Also it does not need a clock recovery circuit because the clock needed is sent out separately through dedicated pads. In AMS verification we target the verification of the complete process: a data is first written into the off-chip DDR memory testbench component, immediately after this the chip goes into its low power state keeping the 10

11 memory in its Self-Refresh mode, then the chip comes out of its low power state, informs the DDR memory component about the same using the RESET and Clock Enable signals and then reads the data from the same DDR memory locations, and finally verifies that the data written and read is the same. Figure 16 Top level block diagram showing the components of a DDR sub-system as part of the SOC To enable mixed-mode verification of this subsystem we keep the I/O pads in SPICE because it is here that the strength of the input and output buffers/drivers can actually affect the slew rate of the data; and the mismatch in this can sometimes lead to a complete corruption of data too. Amongst the I/O pads are the differential clock pads. It transmits a clock that is toggling all the time whether or not Clock Enable for the off-chip DDR memory is high. Thus it is also the one which causes the maximum hit to run time. To overcome this, we took the SPICE view of the clock pad in only one of the basic DDR simulations. Once it was found to be operating correctly, a Verilog model of the Clock pad was taken for the rest of the test-cases. All other DDR pads including data, address and control information pads were always taken in SPICE. The MMDC (multi-mode DDR controller) itself is a state machine and thus can be taken in Verilog without loss of accuracy. Additionally, the off-chip DDR memory itself is present in the form of a Verilog/Vera model. Figure 17 The DDR ZQ Calibration protocol Figure 18 Summary of SPICE and Verilog-AMS view comparison for the targeted checks for the DDR sub-system VII. LCD CONTROLLER VERIFICATION The LCD sub-system contains an on-chip LCD controller that includes Analog and Digital sub-sections. The Analog block is responsible for the generation of various levels of voltages, and consists of voltage references and 11

12 charge-pumps. It uses these generated alternating voltages to drive the Front-planes and Back-planes of an off-chip segmented LCD panel through the analog path present in GPIOs. The Digital block contains registers that hold the user-programmed information that needs to be displayed on the LCD panel. It also controls the configuration settings of the GPIO pads being used to drive the LCD panel. These pads are more often than not, multiplexed to support different functionalities. This LCD controller itself needs to be configured using a processor present inside the SOC. If the SOC has several power-saving then it must be verified that the LCD controller is actively kept in a known state across different modes and also during mode transitions. A clock source is also needed on-chip that is used as the LCD frame clock. Figure 19 Top level block diagram showing the components of a LCD sub-system as part of the SOC In order to verify the functionality of LCD display subsystem on the SOC, the Digital block can be taken in Verilog without loss of accuracy. The Analog block on the other hand performs the function of continuously generating varying voltage levels, by switching on and off several analog paths through multiple multiplexers. Hence a SPICE view of the Analog block is essential to accurately simulate this switching behavior and the loading on the voltage references. A VAMS view of analog block will not be able to provide the required accuracy. Though the SPICE view will be slower compared to a VAMS, it still does manage to run pretty fast due to the simplicity of the Analog block. Similarly, LCD IO Pads must remain in SPICE because the exact potential difference between the front/back planes determine which segment remains OFF or ON under all conditions. Any subtle change in voltage difference on these Pads is crucial to monitor. VAMS view of LCD Pads may not show the exact sensitivity on LCD Pads that are driven on references generated by analog block, therefore it is recommended to go with their SPICE view. Figure 20 Corruption of voltage on a GPIO of the LCD sub-system during Low Power mode exit 12

13 LCD subsystem is an integral part of multiple SOCs with low power modes. One use-case in such a subsystem requires LCD Display to remain intact during changes in power mode. Figure 20, shows the glitches observed on LCD IO voltages during exit from a low power mode. Such cases can only be caught when we keep SPICE view of pads in mixed mode simulations. Figure 21 Summary of SPICE and Verilog-AMS view comparison for the targeted checks for the LCD sub-system VIII. QUANTIFICATION AND CONCLUSION SOC AMS simulations should be performed using a hybrid approach. It is recommended to have full SPICE views for very sensitive analog blocks such as bandgap circuits that do not consume too much simulation time. On the other hand, it is recommended to use VAMS as well SPICE for high speed analog subsystems such as DDR, PLL & LCD that can really slow down the simulations with full SPICE views. Figure 22, below gives a comparison of the simulation run time while using VAMS vs SPICE views for each of the targeted functionalities. Figure 22 Comparison of the simulation run time while using VAMS vs SPICE views for each of the targeted functionalities REFERENCES [1] Comparing Verilog-AMS vs. SPICE view usage for robust AMS Verification of Power Management Controller and Mode Transition, DOI - [2] Verilog-AMS vs. SPICE view: An SoC verification comparison, DOI - [3] Mixed-mode verification of DDR, LCD, and memory sub-systems: Verilog-AMS vs. SPICE, DOI - [4] IC mixed-mode verification: The Sandwiched-SPICE approach, DOI - [5] How an LCD controller drives an LCD glass, DOI - [6] Ramon Cerda, Pierce-Gate Crystal Oscillator, an Introduction, DOI - [7] Behzad Razavi, Design of Analog CMOS Integrated Circuits. 13