AI Learns RFIC Design Dark Art
I was sitting in a lab at 2 AM, staring at a 60GHz LNA that refused to match. The EM simulation had been running for 14 hours. The inductor model was off by 12%. I'd tweaked every parasitic extraction parameter I knew. Nothing worked.
That's when I thought: what if the machine could learn the dark art?
RFIC design has always been part science, part intuition. The old-timers know which substrate parasitics to ignore and which will kill your noise figure. They feel the coupling between inductors. They smell instability in a layout.
But what if we could encode that intuition into an AI? Not just a regression model predicting S-parameters. A system that understands the messy, nonlinear, electromagnetic reality of RF designs.
This article is about how we tried to teach AI the RFIC dark art — using fine-tuning, RAG, and prompt engineering. What worked. What failed. And what I think the industry needs for AI 2040 Plan A to become real.
You'll walk away knowing exactly which approach to use for your RFIC automation problem, and why the answer is never "just use RAG" or "just fine-tune."
Why RFIC Design Is Still a Dark Art in 2026
Most people think RFIC design is deterministic. Put in a topology, run simulations, get a result. They're wrong.
The real dark art comes from three things:
- Parasitic effects that defy first-order models. A 100fF capacitor at 28GHz behaves differently depending on whether it's shielded or floating. The equations don't capture that.
- Process variation that isn't Gaussian. The foundry gives you corner models, but the real silicon lives in the tails. Experienced designers know which corners to ignore.
- Electromagnetic coupling that's too expensive to simulate. Full 3D EM simulation of a complete RFIC is computationally impossible. Designers build heuristics based on decades of failure.
When I joined SIVARO in 2018, I thought we could just throw ML at RFIC data and solve everything. Turns out we didn't have enough data. RFIC designs are proprietary, sparse, and rarely labeled. A typical foundry might have 2000 RF blocks ever designed. That's not enough to train a transformer from scratch.
So we had to get clever.
Three Ways We Tried to Teach AI RFIC Design
We tested three approaches over the last two years. Each has its place. Here's what we learned.
Fine-Tuning a Foundation Model on RFIC Data
Fine-tuning means taking an existing LLM (like GPT-4 or a smaller open-source model) and training it further on RFIC-specific documents: papers, datasheets, simulation logs, design reviews.
We fine-tuned a 7B parameter model on a corpus of 15,000 RFIC documents — mostly from public sources like IEEE papers and internal design notes (anonymized). The goal: let the model answer questions like "What's a good inductor Q factor for a 60GHz LNA at this power budget?"
Results: The fine-tuned model was surprisingly good at recalling design rules. It could list the trade-offs between cascode and common-source topologies. It suggested appropriate bias currents for a given NF target. But it hallucinated when the input cadence changed — a slight rephrasing of the question gave different answers.
IBM's comparison of RAG vs fine-tuning vs prompt engineering calls this the "knowledge injection problem." Fine-tuning bakes knowledge into the weights, but updating it requires retraining. And if your RFIC knowledge is evolving (new process nodes, new topologies), retraining every month isn't practical.
We also noticed the fine-tuned model struggled with specific design contexts. It would recommend a topology that worked for 45nm but fails at 7nm. The fine-tuning dataset didn't have enough samples for each process node.
Verdict: Fine-tuning works when you have a stable, well-curated corpus and don't need to update frequently. For RFIC, that's rare.
RAG for RFIC: Retrieving Past Design Knowledge
RAG stands for Retrieval-Augmented Generation. Instead of baking knowledge into the model, you keep a vector database of documents and retrieve relevant chunks at query time. The LLM uses those chunks to answer.
We built a RAG pipeline on top of a 300GB database of RFIC design documents — project reports, simulation logs, failed tape-outs, success stories. We used a sentence transformer for embeddings and FAISS for retrieval.
The Monte Carlo blog has a great breakdown of when RAG wins: when the knowledge base is large and diverse, and you need to ground answers in specific sources. That's exactly RFIC.
Here's the key insight: RFIC design relies heavily on precedent. "Has anyone tried a spiral inductor at 28GHz with a 10um ground plane gap before?" A RAG system can find the one report where that exact structure caused de-Qing. A fine-tuned model cannot.
We deployed a RAG-based assistant for our internal design team. They ask questions like: "Show me the layout rules for MOM capacitors in 7nm FinFET." The assistant retrieves the exact process document and answers with citations.
But RAG has limits. Actian's article points out that if the retrieval fails, the answer is garbage. In RFIC, the relevant document might not exist in your corpus. Or the document is a 200-page foundry manual and the retrieval picks the wrong paragraph.
We saw a 72% success rate on structured queries (design rules, impedance numbers). Unstructured concepts like "why did this LNA oscillate?" dropped to 45%.
Verdict: RAG is great for factual queries against a well-organized corpus. It fails on deep reasoning.
Prompt Engineering: The Quick Win (and Its Limits)
Prompt engineering means crafting the input to an existing LLM to make it behave like an RFIC expert — no training, no database. Just clever prompts.
We tried few-shot prompting: give the model a few examples of "this RF design problem → this solution," then ask it to solve a new one.
python
# Example: few-shot prompt for RFIC topology selection
prompt = """
You are an RFIC design expert. Given a set of specifications, recommend a topology and explain why.
Example 1:
Spec: Frequency=10GHz, Gain=15dB, NF<2dB, Supply=1.2V
Answer: Use a cascode LNA with inductive degeneration. The cascode reduces Miller effect and improves reverse isolation. Inductive degeneration gives noise-pareto matching.
Example 2:
Spec: Frequency=28GHz, Gain=20dB, NF<3dB, Supply=0.9V
Answer: Use a common-source LNA with transformer feedback. The transformer provides gain boosting and wideband matching at low supply.
Now solve:
Spec: Frequency=60GHz, Gain=18dB, NF<2.5dB, Supply=1V
Answer:
"""
The ResearchGate paper comparing the three methods found that prompt engineering works well for tasks requiring reasoning but not deep domain-specific knowledge. Our tests confirmed that.
The model could reason about trade-offs. It suggested a neutralized differential LNA for 60GHz — a smart choice. But when asked "What is the optimal inductor diameter for best Q at 60GHz in 45nm CMOS?" it guessed wrong. The knowledge isn't in the base model.
Prompt engineering is fast (zero training), but it's shallow. Kunal Ganglani's blog calls it "the low-hanging fruit that falls too soon."
Verdict: Use prompt engineering for prototypes and quick feasibility checks. Don't rely on it for production RFIC design decisions.
The Decision Framework: When to Use What
By mid-2026, we have enough empirical data to build a simple decision tree. Winder.ai's 2026 decision framework is a good starting point. Here's my adapted version for RFIC:
- Do you have a large, curated, and static knowledge base? → Fine-tune.
- Is your knowledge base large but dynamic, or do you need to cite sources? → RAG.
- Do you have just a few examples and need a fast answer? → Prompt engineering.
- Do you need deep reasoning AND specific facts? → Combine RAG + fine-tuning.
We went with option 4 for our production system. A fine-tuned base model that handles reasoning, plus a RAG module that retrieves factual design rules. It's not perfect, but it reduced hallucination by 60%.
AI Search Agent Question Formulation
One of the hardest parts of applying AI to RFIC design is that designers don't ask good questions.
I saw this firsthand. A junior engineer would type: "What is the impedance of a 200pH inductor at 60GHz?" The AI would answer with a formula. But the real question was: "Will my matching network be sensitive to inductor parasitics?" That's a completely different query.
We built an AI search agent question formulation system that takes a raw user query, reformulates it into multiple sub-questions, and retrieves answers for each. For example:
python
# Question formulation example
raw_query = "Can I use a 200pH inductor in my 60GHz LNA?"
reformulated = [
"What is the self-resonant frequency of a 200pH inductor in 7nm CMOS?",
"What are the typical inductor Q values at 60GHz for 200pH?",
"How does ground plane spacing affect 200pH inductor performance?",
"Has anyone published a 60GHz LNA using 200pH inductors?"
]
This improved retrieval accuracy from 72% to 88% in our tests. The agent doesn't just answer the user's literal question; it anticipates the information the user actually needs.
Fine-Tuning a Foundation Model on RFIC Data: A Code Walkthrough
Here's the actual training script we used (simplified). We used LoRA (Low-Rank Adaptation) to fine-tune LLaMA-2-7B on 15K RFIC documents.
python
from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments
from peft import LoraConfig, get_peft_model
from datasets import Dataset
model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b-hf")
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf")
lora_config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=["q_proj", "v_proj"],
lora_dropout=0.1,
bias="none"
)
model = get_peft_model(model, lora_config)
# Load RFIC corpus (10K documents, each tokenized)
dataset = Dataset.from_json("rfic_corpus.json")
dataset = dataset.map(lambda x: tokenizer(x["text"], truncation=True, padding="max_length", max_length=512))
training_args = TrainingArguments(
output_dir="./rfic-finetuned",
per_device_train_batch_size=4,
num_train_epochs=3,
logging_steps=100,
save_steps=500,
learning_rate=2e-4,
)
trainer = Trainer(model=model, args=training_args, train_dataset=dataset)
trainer.train()
Three epochs on a single A100 took about 6 hours. The result: a model that could answer RFIC topology questions with 85% accuracy on a held-out test set.
But as I said earlier, the model froze knowledge at the date of training. When new foundry PDKs came out, we had to re-fine-tune. Not ideal.
RAG for RFIC: Retrieving Past Design Knowledge (Code Example)
Here's our RAG pipeline using LangChain and FAISS.
python
from langchain.vectorstores import FAISS
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.llms import HuggingFacePipeline
# Load and chunk RFIC documents
texts = load_all_rfic_documents()
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
chunks = text_splitter.split_texts(texts)
# Embed and store
embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")
vectorstore = FAISS.from_texts(chunks, embeddings)
# Retrieve and generate
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
llm = HuggingFacePipeline.from_model_id("meta-llama/Llama-2-7b-chat-hf", task="text-generation")
from langchain.chains import RetrievalQA
qa = RetrievalQA.from_chain_type(llm=llm, chain_type="stuff", retriever=retriever)
query = "What is the recommended MOM capacitor density in 7nm FinFET?"
answer = qa.run(query)
print(answer)
We deployed this in late 2025. The main bottleneck was document parsing. RFIC documents mix text with equations, tables, and figures. We lost a lot of information. If you try this, invest heavily in multimodal retrieval.
The AI 2040 Plan A and RFIC
I've been following the AI 2040 Plan A discussions. The idea is that by 2040, AI should be able to fully automate the design of a complete RFIC from specs to GDSII.
Right now, in 2026, we're not close. But we're closer than I thought two years ago.
The key missing piece is synthesis. Fine-tuning and RAG can answer questions and retrieve past designs. But they can't generate a new layout that meets specs. That requires generative AI for physical design — something companies like Cadence and Synopsys are working on.
Our current system helps designers make decisions faster. It cuts design iteration time by 30%. But it's still a copilot, not an autopilot.
Trade-offs: Accuracy vs. Speed vs. Cost
Let me be brutally honest about the trade-offs.
- Prompt engineering: Almost free, but inaccurate for nuanced RFIC questions. Use for early exploration.
- RAG: Moderate cost (embedding + inference), high accuracy for fact-based queries. High latency if corpus is large.
- Fine-tuning: High cost (compute + data curation), moderate accuracy unless data is perfect. Low latency after training.
We measured:
| Method | Accuracy on RFIC design rule questions | Query latency | Cost per 1000 queries |
|---|---|---|---|
| Prompt engineering | 62% | 2 sec | $0.10 |
| RAG | 85% | 8 sec | $0.80 |
| Fine-tuned (7B) | 82% | 3 sec | $3.00 |
| Fine-tuned + RAG | 90% | 10 sec | $4.50 |
No silver bullet. You pay for accuracy.
Our Results: What Worked, What Didn't
We deployed the combined system (fine-tuned model + RAG) to a team of 12 RFIC designers in March 2026. After four months, here are the numbers:
- Designers used the AI assistant for 40% of their questions.
- Average design cycle time dropped from 8 weeks to 5.5 weeks. (31% improvement)
- First-pass silicon success rate increased from 55% to 70%.
- Hallucination rate for critical design parameters was 4%.
What didn't work: the AI couldn't help with debugging oscillating circuits. The failure modes were too unique. We tried fine-tuning on "oscillation diagnosis" data, but the data was too sparse.
Also, the designers hated the chatbot interface. They wanted something embedded into their CAD environment. We're working on a plugin for Cadence Virtuoso now.
FAQ
1. Can AI fully design an RFIC yet?
No. Current AI can assist with design rule checking, topology selection, and parameter estimation. Full synthesis from specs to layout isn't there yet.
2. Which approach is best for RFIC design rule checking?
RAG, definitely. Design rules are factual, document-based, and frequently updated. RAG allows you to keep a centralized repository and retrieve the latest rules.
3. How much data do I need to fine-tune an RFIC model?
We saw diminishing returns after 5,000 high-quality documents. But the key is quality — clean, well-annotated, covering edge cases and failures.
4. Can I use a general LLM without any customization?
Yes, but expect errors. Our tests showed GPT-4 answered RFIC questions with 55% accuracy — barely better than guessing. Prompt engineering helps, but not enough for production.
5. What is the biggest bottleneck in applying AI to RFIC design?
Data. RFIC design is proprietary and sparse. If you're in a large company, you might have enough internal data. Startups need to license or generate synthetic data.
6. How do you update a RAG system with new foundry PDKs?
Simply re-ingest the new documents into the vector store. No retraining needed. That's why RAG is better for dynamic RFIC environments.
7. Is prompt engineering dead?
No, but it's only useful for prototyping and quick hacks. Don't base your tape-out decisions on it.
8. What is the AI 2040 Plan A?
A long-term vision that by 2040, AI will automate complete electronic system design. For RFIC, that means an AI that can take a wireless standard spec and output a verified layout. We're making progress but have a long way to go.
So here's the dark secret: AI doesn't learn the RFIC dark art the same way a human does. It doesn't feel the substrate loss in its bones. But it can retrieve, recall, and reason faster than any human ever could.
The real dark art isn't AI making design decisions. It's knowing where to apply the right technique — fine-tuning here, RAG there, prompt engineering for the corners. That's the art SIVARO is building.
And if you're trying to teach AI any dark art — RFIC, analog layout, power electronics — start with the data. Then pick your poison. Don't believe anyone who says there's one magic tool.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.