guide to analog ip

What is analog IP?

Analog IP generally handles every feature on a chip that connects to the outside world, plus power management and clocking. Analog IP is an essential part of every IC or SoC, but is often overlooked until late in the development schedule as it often provides system control and management functions.

Typical analog IP includes: Power on Reset (POR), Low-dropout regulators (LDO), Switch-mode power supplies (SMPS), Glitch detectors, Analog to Digital converters (ADCs), Digital to Analog converters (DACs), Oscillators, PLL/DLLs, Crystal oscillators, IO pads, PHYs, SERDES, and Low-Noise Amplifiers (LNAs).

The main challenge with analog IP is that it needs to be redesigned for every process, and often the correct configuration is not available off-the-shelf, and so manual work is required to fit the design to the application.

If left late in the schedule, this can cause tapeout delays, or can prevent the final chip from working properly due to rushed IP delivery. In addition, as manual work is often required, this can substantially increase the cost of the analog IP either upfront due to the engineering effort involved, or later due to the die area implications to the chip.

Why do I need analog IP?

Every chip requires some form of analog IP. Digital logic relies on a controlled supply voltage, a high-speed clock, and inputs from elsewhere on the PCB. All of these involve analog signals. Even digital interfaces such as DDR pads or Serdes involve primarily analog IP, as digital signals are just a two-state approximation of an analog system. Whereas with digital logic, this works effectively, when communicating off-chip, the inherently analog features of transmission lines - their inductance, resistance and capacitance - mean that the circuits need to be more complex to work effectively. This relies on analog design.

As a result, every chip needs analog IP. Some can use the bare minimum - a reset controller, voltage monitor, clock generator and IO pad library. However, those companies that integrate more IP can reduce the effective cost of their system very substantially.

What are the benefits of integrating analog IP?

Most real-life systems combine both analog and digital components to form a system - for example a voice-operated digital assistant contains a variety of CPUs, digital interconnect, memory and peripherals, all of which are digital. But it also contains multiple ADCs (for the various audio channels) and a DAC (for the loudspeaker output), an RF interface (for the Bluetooth and Wi-Fi signals), 10 different voltage regulators (to control the power supplies), PWM LED drivers (to drive the pulsing LEDs on the top), and a PMU (to control the main CPU voltage and startup sequence). All of these components are analog functions, and all of them are separate discrete devices in the system.

There are significant benefits to integrating additional analog IP into the main SoC. Most notable is cost - often a 10x reduction in analog component cost can be achieved by integrating analog IP, as for simple functions there is significant overhead in area for bond pads, packaging and logistics cost, which vanishes when analog IP is integrated. The other significant benefit is in supply chain logistics: reducing the number of external components eases the supply chain hassle associated with the system build. It also reduces the amount of second sourcing that needs to be arranged, which dramatically reduces the complexity of the supply chain.

What should I look for in analog IP?

When purchasing analog IP, there are both technical and non-technical factors to consider. The complexity of IP delivery is often underestimated: delivering a block from one company to another is often harder than many people think, and so it is important to assess not just the technical fit, but also the broader quality, support and commercial factors associated with buying IP.

Technical factors

There are a number of technical factors to consider when buying IP - some examples include:

  • Performance - does this meet expectations? Is the performance greater than needed, and therefore will waste power/area?
  • Feature set - does this include all features needed? What about power-down modes?
  • Area and aspect ratio - does the area appear acceptable? Does the aspect ratio fit with the floorplan of the chip?
  • Integration needs - does it integrate pads and ESD structures?
  • Configuration and changes - are there any changes to the IP that are needed to fit it into the application? Is the metal stack correct for the process being used? Are the power domains and transistor types correct?

There are many other technical factors associated with IP which need to be evaluated. However, any factors which do not meet the requirements need to be evaluated, and a judgement on whether they need to be changed. Some changes, such as transistor types or the metal stack, appear simple but the changes can be costly, and can also add significant risk to a project, particularly in advanced node technologies.

Non-technical factors

There are a number of really significant non-technical factors to consider also:

  • Licensing model - up front fee, royalties, and the basis for change requests
  • Changes required to the IP - often a Time and Materials basis for even simple changes can increase the cost of an IP block substantially, and also add significantly to the risk and schedule
  • Cost basis - how much system-level cost can I save through using this IP on my chip?  What is the cost penalty of using the IP selected that may be bigger than other IP options? Am I trading off up-front cost for a much bigger penalty in production cost?
  • External components - how many external components can I eliminate by using this IP? Are there any additional components that are needed based on this IP compared to IP from other suppliers?
  • Quality - what is the quality of the IP? Is an example of delivered IP available? Does the customer receive documentation before the IP?
  • Test silicon - has the block been proven on test silicon? Was it on this process, and with this architecture? Are there any changes being proposed that render the test silicon redundant?
  • Support model - how will support be performed? Where is the support team? Is support provided just for the IP delivery, or through to production?
  • Design knowledge - are the designers of the IP still available to answer questions, or is this legacy IP which has been ported through many generations? When was this IP design completed? Was it a long time ago, and if so would we be able to get support for the IP today?
  • IP completeness - are the IP deliveries consistent and complete? What checks have been completed prior to delivery? Is the customer expected to run a significant portion of validation once the design comes in-house?
  • Delivery time - when will I get the initial views? When will I get the final delivery? What will change between the two? Who will be making the changes, and what validation will take place after those changes have been made?

These non-technical factors are often overlooked in the selection of IP, and yet should have equal weighting with the technical assessment. In particular, there are factors here that can have a very substantial impact on the risk associated with the IP, which can often be under-estimated in the selection of IP.

What should I be concerned about in analog IP?

Although analog IP adds significant value to any SoC, there is evidence that analog IP is responsible for a number of IC re-spins and production issues. Most of these issues can be traced to the non-technical factors affecting the deliverable, rather than resulting from a poor specification or a simply infeasible architecture.

When reviewing analog IP, it is crucial to go beyond just the specifications, to understand as well the background to the IP, the current use patterns, the changes required, and whether it has been used on this process before - and to give these equal weighting to a set of technical parameters associated with the IP selection.

In many situations, it is the interaction at this point - small technical changes that snowball into major engineering challenges - that causes inadvertent chip failures later in the production flow. At this point, the cost of a non-functional IP can run into the millions or tens of millions of dollars, depending on when it is detected.

The best way to understand the IP that is being purchased is to analyse its history: when it was produced, how recently it has been updated, what the terms would be for any modifications, whether the original engineers are still available, the quality and consistency of the documentation and deliverable package, and the knowledge of the support engineers. By reviewing all these aspects, purchasers can reduce the chances of production issues leading to costly re-spins.

How does Agile Analog help?

Agile Analog has developed a unique COMPOSA methodology, which transforms the way analog designs are created and delivered.  Using our technology, designs are created specifically for your application, based on your requirements using our latest rules-based AI design recipes. The design is optimised for your process, and our repeatable, systematic methodology enables us to recreate and modify your design with complete reassurance. For each of the key care-abouts above, the COMPOSA methodology helps address these concerns:

  • Performance - optimised specifically for your application needs, giving you optimal PPA
  • Feature set - add or remove features easily to save area
  • Area and aspect ratio - adjust the aspect ratio and performance/area trade-offs at IDP delivery time
  • Process - select any process or process variant, and be confident that the performance is optimal for the transistor types available
  • Configuration and changes - select your own metal stack, process configuration and design parameters to meet your needs
  • Licensing model - simple licensing model works with your needs to balance up-front fee vs royalty
  • Changes required to the IP - changes can be added easily up to IDP sign-off
  • Cost basis - drastically reduce the cost of your product by integrating more analog IP on-chip;
  • External components - make trade-offs to optimise the balance of internal and external components
  • Quality - our unique delivery checker ensures all views are consistent. Our auto-generation approach and validation strategy assure the highest quality deliverables
  • Test silicon - COMPOSA has been proven on test silicon, and we continue to run example blocks on multiple shuttles. Talk to us if you would like your configuration to feature on a test shuttle.
  • Support model - our comprehensive application support team is a regular part of our engineering team, and taps into our architects to answer your questions.
  • Design knowledge - all our designs are codified in COMPOSA to ensure that not only the design, but the design intent, tests and signify criteria are all included, making the IP simple to support and modify
  • Delivery time - we have conservative delivery time estimates in our contracts, and provide schedules that you can plan your tapeouts on. We deliver initial views early in the process, and work closely with customers to ensure any changes are well understood prior to final delivery.

Using its COMPOSA technology, Agile Analog is committed to delivering the highest quality IP to customers. Speak to us for more information.

back