Stop Asking If Analog Is Dead. Start Asking If You Can Define a Spec.

At 1:30 a.m., only one workstation in the lab is still on. On the screen, a differential waveform collapses at a certain corner. You have been tuning the common-mode feedback for three hours, and it still hasn’t converged. You open Zhihu and search “Does analog IC design still have a future?” Two high-upvote answers appear: one says “Run,” the other says “Older engineers are more valuable.” You close the page. The waveform is still that waveform.

Other people’s experience is always like a little horse crossing a river: everyone finds a different depth. Objective reality, after being filtered through different engineers’ subjective views, presents wildly different waveforms. The words below are just the output of my particular filter. Take them or leave them.

1. Do a concrete calculation first, instead of talking abstractly about “decency”

Maslow’s hierarchy of needs isn’t necessarily rigorous, but it’s good enough for a coordinate check on yourself.

First layer: survival and safety. For a graduate with an analog MSc from a top-985 university who seriously follows the technical path, in a first-tier city, after three to five years the monthly salary is roughly RMB 25k–40k; after five to eight years, if the direction is right and the company isn’t too bad, an annual salary of RMB 600k–1M is possible; beyond eight years, divergence becomes large. Some keep doing blocks, some lead teams, some move into architecture, some go to foreign companies or startups. Rent or mortgage, living costs, savings rate: these specific numbers differ for everyone, but the conclusion is roughly the same. Decent survival is very likely not a problem, but it is not a guaranteed promise. Industry cycles, company fortunes, and direction choices will all make this curve fluctuate. Treating “RMB 1M after seven or eight years” as a sample observation is fine; treating it as an employment contract is lying to yourself.

Second layer: group identity and respect. An urban white-collar worker, nothing particularly special. In social narratives, the identity of an engineer is neither deified nor belittled. Real respect does not come from a title; it comes from whether you can solve problems others cannot. If you push an ADC’s SFDR from 70 dB to 80 dB, someone on the team will remember you; if you only run simulations and wait for others to give you specs, no one will remember you.

Third layer: self-actualization. Stretched over a career of decades, interest, curiosity, and the sense of conquest are the underlying support. But interest cannot be verified only by imagination. Are you really willing to repeatedly scrutinize a noise spec? Can you really find pleasure in a tape-out failure? These questions are closer to you than “Does analog have a future?” If for three consecutive months you want to shut down the computer every time you see a waveform, that may not be the industry’s problem.

2. Go deep on modules, but don’t just stare at circuit schematics

Module-level design (PLLs, ADCs, and so on) needs to be done precisely and deeply in the early-to-mid career. There is no shortcut. But going deep does not mean staring only at the circuit schematic.

For example. You are working on a PLL in a SerDes. The system engineer gives you a jitter budget: the entire link is 1.5 ps RMS, and the PLL gets 0.3 ps. If you make the PLL 0.25 ps and call it done, that’s not wrong. But if you can draw a link diagram marking which offset frequency bands of the PLL’s phase noise affect the CDR and which bands are filtered out by the channel, you can discuss with the system engineer: can this budget be reallocated? Is VCO noise above 10 MHz more important or below? How do you trade off reference clock jitter against PLL bandwidth?

This diagram doesn’t need to be beautiful; hand-drawn is fine. But it determines whether you are “someone who receives specs” or “someone who sets specs.” In an interview, when asked “Why did you set this ADC’s sampling rate at 2 GS/s?”, answering “The system gave it to me” and answering “Because the channel Nyquist plus 20% margin, while also considering the power tradeoff of the downstream DSP” are two different evaluations.

Control over SoC architecture doesn’t mean you should grab the architect’s job. It means you know your module’s position in the system: who it interfaces with, how its noise affects the link budget, how its power affects the overall solution, how its mismatch affects yield, how its stability affects startup and protection. Engineers who can explain these clearly and engineers who can only run simulations have different career ceilings.

3. Code is not a bonus skill; it is a basic capability

Mathematical abstraction of non-idealities and behavioral modeling will increasingly look like a basic capability rather than a bonus. Verilog-A/AMS, Matlab, and Python: you will most likely not escape them.

To be specific. After you finish an ADC, you run 100 corners. Each corner has 5 temperature points, 3 supply voltages, and 3 process corners. That’s 4,500 simulations in total. You open the results in Excel and look for the worst group by eye. It takes two hours. If you know Python, you write a script that reads the simulation results, sorts by SNDR, and automatically marks the corner combinations corresponding to the failure boundary. Twenty minutes, done. You can spend the saved time analyzing why that corner collapsed instead of burning it on finding data.

To be even more specific. You are designing a chopper-stabilized op-amp. One transistor-level simulation takes two hours. You write a Verilog-A behavioral model that abstracts the chopping frequency, residual offset, and noise folding. It runs in ten minutes. First you see the system-level impact clearly, then you return to transistor level to close it out. The behavioral model does not need to be perfect on the first pass; it needs to align with transistor-level simulation. The alignment process itself is the process of understanding non-idealities.

Coding ability brings not only efficiency but also expressiveness. If you can abstract a problem into a model, you can communicate more efficiently with system engineers, digital engineers, and test engineers. If you can automate simulation-result analysis, you can find the real failure boundary faster from a large number of corners. If you can write design intent into reproducible scripts, you can turn experience from personal memory into a team asset.

4. Use gm/Id to build intuition, use tools to explore, but don’t outsource judgment

gm/Id can help engineers build good design intuition, but it is not necessarily the most efficient path. Optimization tools such as AOP are already powerful and can fully cover small-scale designs such as op-amps and comparators, freeing engineers from tedious tuning.

But tools cannot replace understanding. A concrete flow might look like this: you use gm/Id to hand-calculate the initial sizing of a two-stage op-amp, setting the input pair’s gm/Id at around 15 and the load device’s gm/Id at around 8, obtaining a rough W/L. Then you enter the constraints into AOP: gain greater than 80 dB, phase margin greater than 60 degrees, unity-gain bandwidth greater than 500 MHz, power less than 2 mW. The tool produces a set of sizes, and the simulation results look good. Then you run corners and find that at the SS corner, 125°C, and 10% lower supply voltage, the phase margin drops to 45 degrees. The tool will not tell you why. You need to judge for yourself: is it because the output impedance drops too much with temperature, or because process variation in the compensation capacitor moves the pole? This judgment cannot be given to you by a tool.

A more efficient path may be: use gm/Id to build first-order intuition, use optimization tools to explore the design space, then use Spice and corners to verify and close out. Tools liberate you from tedious tuning, not from judgment. Discussions about analog design automation at ISSCC and VLSI are also not centered on “tools replacing people,” but on “how to divide labor between people and tools.”

5. Digital demand is larger, analog has not died, but jobs are diverging

Digital demand is far larger than analog demand. This is the objective reality of the industry today. But analog has not been marginalized.

Look at two directions specifically. In AI infrastructure, the physical layer of high-speed interconnect is moving from 112G SerDes to 224G. Speed doubles, channel loss becomes larger, equalization becomes more complex, and the bandwidth, linearity, and noise of the analog front end are being pushed to tighter boundaries. Optical interconnect driver circuits, TIAs, and CDRs all need analog engineers. Another direction is power management. Power consumption of AI servers is rising, and the efficiency and transient response requirements of multiphase bucks, LDOs, and PMICs are becoming increasingly stringent. These are not things “digital can casually do on the side.”

If you often look at industrial results at ISSCC, you will not feel that this is a dying field. But note that jobs are diverging. One type is the tuning job: you are given a mature architecture, you size it well, run corners, and coordinate with layout. This type of job is highly competitive because replaceability is relatively high. The other type is the architecture job: defining specs, decomposing budgets, choosing topologies, and judging failure boundaries. This type of job is scarce because it requires system perspective and judgment. Not every analog position will automatically give you architecture training; you need to actively seek it.

As long as humans still survive in the Physical World, analog will have room to play. But for individuals, this sentence is an opportunity; for the industry, it is also a filter. What is lacking is not Spice Monkeys who can only do hard labor; what is lacking is professionals who can analyze problems, decompose specs, and define architectures.

6. Things you can do next week

Turn the above into actions. Don’t write empty phrases like “study more.” Next week you can do these things:

Choose a module you are currently working on and draw a diagram of its position in the system link, marking where its input and output specs come from and whom they affect. Hand-drawn is fine; take a photo and keep it.

Write a Python script that reads the results of your most recent corner simulation, sorts them by the metric you care about most, and automatically marks the three worst groups. If you don’t know how to write it, ask ChatGPT and learn while writing.

Find three industrial papers from ISSCC or VLSI. Don’t just look at the circuit diagrams; look at how they define the problem, decompose specs, and connect to system specs in the Introduction. Write three sentences for each: what problem they solved, what architecture they used, and what the cost was.

Use gm/Id to hand-calculate an op-amp or comparator you are familiar with, then optimize it with AOP or a similar tool and compare the results. Record which corner the tool’s solution fails at first, and think about why.

7. After you shut down the simulator

At 2 a.m., you finally get the common-mode feedback to converge. The waveform passes spec at all corners. You save the results, shut down the simulator, peel off the keyboard cover and shake off the dust, and the pothos leaves look a little wilted, so you water them. Tomorrow you still need to run post-layout simulation; the day after tomorrow you need to align with the layout engineer. The waveform will collapse again. You’ll fix it. That’s the job. May the Analog be with you.