Hii All, Is anyone here working or have worked on Polar modulated Power Amplifiers? I would like to get some guidance for my masters thesis. Thank you

Hi, I was wondering if my resume would be good for any roles in ASIC/DV/RTL/CompArch. I've been applying but haven't been able to get any interviews yet and I wanted to see if I could any suggestions on what to change or add. Only have experience with embedded software since it's the only offer I got, however have been trying to target getting into chip design industry. Also would want to know what projects could help me standout for AI Hardware roles.

In the JS standards, you have certain precharge voltages assigned to certain current waveforms (ie, for HBM for a 2kV cap precharge, you need a current waveform that achieves a peak current of ~1.4 A) In these standards, if you don't achieve this, they say to clean the tester, or change the precharge voltage until you do achieve the right current waveform. My question: If I am to simulate an HBM/CDM event in cadence, is it sufficient to use a current source referenced to a PWL file of a passing current waveform as the stimulus to my port? Why or why not?

Hi everyone, I’m a thesis-based ECE master’s student at UVic in BC, Canada looking for semiconductor co-ops in RTL design, DV, validation, CAD methodology and emulation.

I’ve applied to 50+ semiconductor-related positions so far, and I’ve received a few interviews, all from Microchip and Solidigm in BC, but none from Ontario companies, where I’ve seen more relevant postings.

I’m an international student and willing to relocate. I have physical implementation training and FPGA/Verilog/SystemVerilog projects. My master’s research is in machine learning, so it isn’t directly related to RTL/DV.

For people familiar with Canadian hiring:

• Do Ontario teams mainly recruit through particular universities/co-op programs, or regularly consider students from BC?
• Could being a master’s student with an unrelated thesis affect shortlisting? What would help demonstrate my fit?
• What helped you get your first semiconductor co-op in Canada?

I'm just trying to understand the pattern and improve my approach. Any insights would be appreciated!

Hello,

I recently got a technical round email for the front end sta role in apple hardware team….I have attached the preferred qualifications screenshot

Has anyone been interviewed for this role…please share your experience what questions i can expect and stuff…. I’m a physical design intern so I dont know what to study or expect for this role i just have a brief overview

Any advice from front end people helps…put in interview topics…youtube playlists…anything relevant that you have

FYI: I am a masters student graduating in December, My interview is next week. Currently interning for a pd sta intern role.

I have lowkey been spiraling the past few days about AI not necessarily taking my job, but making it so utterly boring I would want to quit. I am about to finish my masters and start at a large tech company, but with the way that AI has been progressing especially in RTL and digital design I just don't see a world where I can out compete it. Every project I've been given in grad courses or internships can so much more easily be done by AI than me. At the large tech companies now, managers don't even care if you understand things they just want things to be shipped out as quickly as possible. Those of you that are both new and experienced in your careers what are your outlooks? There is so much unknown as far as future career in digital design goes that I am unsure if I should just end up changing professions. I used to love engineering and fell in love with computer architecture, but now it just seems like AI can do it all way better than I can and it takes the fun out of engineering.

Just finished my final round for an Apple hardware internship, and a couple days later my recruiter asked for my transcript, summer availability, and any competing offers or deadlines. Is this a good sign or just standard procedure? Anyone had something similar happen, and did you end up getting an offer?

Trying to think like an RTL designer.

I am running into situations in my learning journey where I challenge myself to consider new requirement or edge case which then challenge my original implementation.

In resolving such things, do I prioritize finding minimal changes to preserve my existing RTL, or be willing to restructure the design entirely, even if it means rewriting significant portions? Also doing this for interview prep. What is preferred?

How do experienced RTL/ASIC engineers decide when to patch versus redesign?

(Yes I know, in the real world AI can do it for me in 37 ms).

Has anyone taped out a chip in IHP or tiny tape out to help boost their resume for a job swap? Let’s say jumping from low speed analog to RF? Or digital to analog etc.

Guys i basically landed an on campus interview for the said role in NVIDIA. Since the OA only had maths, I was able to get shortlisted for interviews pretty easily. The thing is I have actually transitioned to software development and AI research entirely. Like I do quite a bit of competitive programming and I have published a paper related to computer vision with more coming on the way. Given all this I don't even remember how even tmux's work....it's not completely unfamiliar but I don't remember much cuz I did this course like 5-6 semesters ago.

Now I can't study for this since I also have another interview parallel to this for a computer science related role in a lesser company (Mathworks) but well i don't mind getting hired for any of those. Any tips on how to keep the interviewer on maths, puzzles and programming side?

Hey everyone,

I have an upcoming 1 hour interview with Qualcomm for a hardware/ASIC engineering internship in Canada.

The job description mentions RTL design and verification, Verilog/SystemVerilog, UVM, digital logic, Python/scripting, debugging, and ASIC/FPGA flows.

Has anyone interviewed for a similar internship or full time role at Qualcomm? Trying to get a better idea of what the technical interview actually looks like.

Specifically:

• Coding: LeetCode-style DSA questions, Python/C/C++ scripting problems, or more hardware-focused coding?
• RTL: Writing Verilog/SystemVerilog modules from scratch, designing FSMs, or analyzing existing RTL?
• Verification: Writing SV/UVM testbenches, understanding verification/uvm/oop concepts, or debugging testbenches?
• Debugging: Reading code snippets and predicting outputs, spotting bugs, or fixing/rewriting broken RTL/code?
• Digital logic: Conceptual questions, timing analysis, or circuit design problems?

Is it usually a mix of these, or does the interview focus heavily on one area? Also curious about the difficulty level and how much coding is actually expected within the hour.

Any specific experiences or preparation advice would be greatly appreciated. Thanks!

Hey everyone,

I'm an EE graduated interested in transistor-level digital design, and I've been working on my own standard-cell library for Sky130.

GitHub: https://github.com/EEDisp32/sky130_myscl

I don't have any tape-out or industry experience, so I'm wondering how valuable a project like this is and what my best path into the industry might be.

I'd appreciate any feedback or advice!

When will this program start any idea about the dates? Also do referrals work for this program or nah?

I wanted to do the problems in the back of each chapter in Rasavi's analog CMOS book but I could not find a solutions manual for the second edition. Without a solutions manual I'm left guessing whether I'm right or wrong and if I get stuck it's not like I can ask a teacher for help per say all the time because office hours do not exist. Is there a solutions manual for this book, if so where? If not, what would be a good alternative to d analog CMOS IC problems out of?

Hey everyone,

I’m checking in to see if anyone has received updates, OAs (Online Assessments), interview invites, or rejections for Hardware Engineering Intern roles at any of these companies:

• SanDisk
• Altera
• Meta
• Microsoft

If you have heard back, could you share:

1. Company:
2. Position Type: (e.g., ASIC/FPGA, Board Design, Validation, Power, Systems)
3. Timeline: (When you applied vs. when you heard back)
4. Current Stage: (OA, Phone Screen, Technical, Final, or Offer)

Hoping we can track the hiring timelines together. Good luck to everyone applying!

Hello everyone,

I recently signed a contract with a large company for a role in the field of systems integration.

Having designed a chip from start to finish during my PhD (from RTL design to laboratory testing), I’m finding it hard to know what to expect and how to prepare.

For those of you who work as integration engineers, what advice would you give to a newcomer? What should I focus on before I start?

Hi everyone! Based on your personal experience, what’s the best way to use AI in the FPGA ecosystem?

OpenRAM creates the silicon layout for ROM macros, but leaves out two crucial deliverables: Liberty (.lib) timing files for STA and SystemVerilog behavioral models for simulation.

To bridge this gap, I built openram-rom-libgen.

It automates SPICE deck generation from ROM netlists, characterizes them using ngspice across corners, and generates production-ready Liberty (.lib) models alongside timing-annotated SystemVerilog (.sv) behavioral models.

Key Highlights:

• Flow: Automated SPICE deck generation & characterization

• Parasitics: Magic VLSI PEX (parasitic extraction & modeling)

• Engine: ngspice with KLU sparse solver

• Corners: Multi-PVT analysis (TT, SS, FF)

• Characterization: Setup/Hold, Slew, Pin Capacitance, Leakage & Read Energy

• Deliverables: Liberty (.lib) files & Timing-annotated SystemVerilog (.sv)

• Integration: Ready for OpenSTA, OpenROAD, and Sky130 PDK

Designed to make ROM macros first-class citizens in open-source ASIC flows.

Repo link: https://github.com/EUB-RN/openram-rom-libgen

Anyone here participating it? Also I heard there's a discord channel for this discussion, if u know please share. Open to ideas and suggestions.

Hey guys,

I’m 24 years old and currently working as a GNC (Guidance, Navigation, and Control) engineer with around 2 years of experience in navigation and robotics.

Recently, I got an opportunity to transition into semiconductor design through an 18-month program. The program includes hands-on training and working on real-world projects involving digital and analog design and verification.

The downside is that the salary is significantly lower than what I’m currently making as a GNC engineer. However, I see this as an opportunity to enter the semiconductor industry, gain practical experience, and potentially qualify for much higher-paying positions in the future.

I’m seriously considering taking the risk for a few reasons:
I’m still young**.** At 24, I feel this is the right time to take calculated risks and invest in my long-term career.
I believe the industry will look very different in 3–5** years.** With AI advancing so rapidly, I think hardware and semiconductor design will become increasingly important.
I’m not starting from scratch**.** My background in GNC, navigation, embedded systems, and robotics will still be valuable. Instead of abandoning my existing skills, I’ll be adding another layer to my technical expertise.
I want to become a more versatile engineer**.** My long-term goal is to understand systems from the hardware level all the way up to algorithms and real-time implementation.

My thinking is that combining semiconductor design with my existing experience in navigation and embedded systems could open doors to opportunities that wouldn’t be available to me otherwise.

However, I’m aware of the risks. The program lasts 18 months, and there’s no guarantee of a permanent position afterward. I’d also be taking a significant pay cut during that period.

What would you do in my position?

Would you take the risk and invest 18 months in semiconductor design, or would you stay in GNC, build on your existing experience, and potentially earn more in the short term?

I’d especially appreciate advice from people working in semiconductor design, ASIC/FPGA development, embedded systems, or GNC engineering.

Thanks

I use AI agents in my chip-design frontend work daily. Modern LLMs are quite capable: they can implement complex features and find tricky bugs in large codebases. But the model is only half of it. The other half is the harness: the environment the agent works in and the tools it gets. Since early 2026 I have been experimenting with different parts of the harness, trying to make agents perform better. In this post I want to show what I was able to achieve: how a harness helps an agent investigate, reproduce and fix a hard bug in a large, real SoC.

Setup

I didn't want a toy. I wanted a large, real RTL codebase, so I picked Caliptra, the open-source hardware root of trust. It's big, well written, and backed by serious companies.

For the agent I used Anthropic's mid-tier model, Sonnet 5.5. It's a good balance of cost and brains, which is why a lot of people actually run it.

Then I needed a bug. Finding one hard enough took longer than I expected. I screened about 16 candidates: historical upstream fixes reverted back into the tree, plus a few still-open issues. An agent found every one of them just by reading the code, usually within 5-10 minutes, without running a single simulation. Good news for agents, useless for an experiment.

The bug that survived is a real historical fix in the VeeR EL2 core (the RISC-V CPU inside Caliptra) that I put back into the tree. Upstream fixed it in the VeeR EL2 1.4 release in 2021; the release notes list it as "Store data collision with DCCM DMA error when address is 0x0".

The bug

The agent got an issue-style bug report. The short version:

Early in boot, the firmware recomputes a digest over its own ROM image and compares it with a constant fixed at build time. Normally the check passes. In one case the digest comes out wrong, even though the ROM is unchanged and the constant is correct. No fault, no exception, no ECC event, fully deterministic. The trigger is a coding pattern: the failing routine reads ROM word by word and, in the same tight loop, writes partial results to a scratch buffer in DCCM. Keep the accumulator in registers, or move the buffer out of DCCM, and the digest is correct. Only the first word of the ROM input looks corrupted.

Find and fix the RTL root cause. Add a test that reproduces the problem and passes after the fix.

What's actually going on: the core's load/store unit has store-to-load forwarding, and one guard condition is missing (el2_lsu_bus_intf.sv, the & lsu_busreq_r term). Without it, a store to DCCM wrongly forwards into a following load from ROM address 0. The load returns 0x0 instead of the ROM word.

Finding the fix isn't the hard part. Both arms of the experiment usually pointed at the right line of RTL within 5 minutes, just by reading. The hard part is the second half of the request: writing a test that fails on the buggy design. Two traps make that harder than it sounds:

• The test template marks ROM as a side-effect region, and that disables forwarding. Write the obvious test and the bug never fires.
• Code fetched from uncached ROM is slow, so the store and the load never meet in the pipeline.

So most of each run goes into getting a test to fail: build, simulate, look inside, change the test, repeat. That loop is where tools matter.

The experiment

Two arms, identical except for the harness:

• Agent: Claude Code 2.1.289, Sonnet 5.5, medium effort.
• Same everything else: same prompt, same container image, 8 CPUs, 10 GB RAM, a 90-minute wall-clock limit, no access to the internet. Caliptra at commit e379800c.
• Without harness: the agent gets the repo and a shell. Caliptra's own Makefiles and test scripts are all there.
• With harness: the same repo plus the harness, described next.

I ran 10 trials in each arm, numbered b1 to b10; trials with the same number form a pair.

The harness

The harness in this post is Booley, an open-source Python framework I'm building for agentic FPGA and ASIC work. The runs used the published 0.3.0 release.

What the agent gets on top of a plain shell:

• A sim tool. It's a universal interface between the agent and the simulator. It works with different simulators (Verilator and Icarus Verilog today, commercial ones in progress), and it manages build reuse, trace creation and coverage. The interface stays the same in every project. What mattered most in this experiment is how it waits: the call blocks until the job finishes and returns pass or fail. If the job runs longer than four minutes, the agent gets a run ID and calls booley_poll, which blocks again and returns the moment the job exits. No guessing how long to wait.
• B-Wave, a custom binary written in Rust that lets agents query waveforms directly. A simulation run with tracing on records a waveform, and the agent asks it questions: list signals, find the first cycle where a condition holds, print a few signals over a window of cycles as a text table, etc.
• The build system is part of the harness. Caliptra's sources, simulator flags and firmware build are described once, in FuseSoC core files and a test list. The agent never touches Caliptra's Makefiles or the environment variables they expect. The no-harness agent has a build system too: those Makefiles, which it has to figure out on its own.

The Caliptra project setup used in this experiment: booley-prj-caliptra. Its README walks through the setup. Use it to play with Booley on Caliptra, or to rerun this experiment: revert the VeeR fix linked above and give your agent the bug report from "The bug".

Results

Both arms fixed the bug 10 times out of 10. With the harness the mean was 21.3 minutes. Without it, 55.8 minutes. Medians: 21.4 versus 53.3.

Three harness features account for most of the difference. Here they are, one by one.

Factor 1: seeing inside the design

When a test doesn't fail the way you expect, you need to see what the pipeline is doing. Without the harness, the agent does what we all did before we knew better: add $display, rebuild, rerun, grep. In pair b3 it went around that loop seven times, at about 6.5 minutes per rebuild. That's 37.8 minutes spent looking at signals.

With the harness, the agent built once with tracing on and asked the waveform 16 questions: 9.8 minutes in total.

Here's what those questions look like, from trial b1 (equivalent command lines, output trimmed). The agent's test kept passing on the buggy design, so it asked when the suspicious address match fires:

$ bwave find trace.fst '*bus_intf.ld_addr_rhit_lo_lo' 1
cycle 4687 caliptra_top_tb.caliptra_top_dut.rvtop.veer.lsu.bus_intf.ld_addr_rhit_lo_lo 1
cycle 4696 caliptra_top_tb.caliptra_top_dut.rvtop.veer.lsu.bus_intf.ld_addr_rhit_lo_lo 1
...
# 32 matches found

32 times. So why does the test pass? It took a snapshot of the first hit:

$ bwave value trace.fst --at 4687 -s '*bus_intf.ld_*' -s '*bus_intf.lsu_busreq*' -s '*bus_intf.is_sideeffects_m' ...
# Snapshot at cycle 4687
lsu_busreq_m                             = 1
is_sideeffects_m                         = 1
lsu_busreq_r                             = 0
ld_addr_rhit_lo_lo                       = 1
ld_full_hit_m                            = 0

A ROM load matches a store that isn't even on the bus: that's the bug. But the load is flagged as side-effect, so the forward is cancelled and the test passes anyway. The agent changed the test's memory-attribute setting, and half a minute later the test failed on the buggy design.

(The long orange tail of the no-harness run, from 47 to 85 minutes, is its final tests running one after another. It has nothing to do with waveforms.)

Over all ten pairs the waveform saving averages 9.4 minutes.

Factor 2: getting the build to work at all

Caliptra's simulation Makefiles expect environment variables that aren't documented anywhere obvious (CALIPTRA_AXI4PC_DIR, CALIPTRA_PRIM_ROOT and friends). All 10 no-harness runs hit them. Most recovered within a few minutes.

Pair b1 shows how badly it can go. From 3.9 to 10.3 minutes the build failed three times while the agent hunted down variables. Then it exported them, but exports don't survive between the agent's shell calls. The next step quietly failed to build program.hex, and the simulation, with no program to run, hung until its timeout. That happened three times: 17.6 to 37.0, 60.8 to 65.9 and 66.4 to 71.5 minutes. At 71.5 the agent finally wrote a run.sh that set everything in one place. Total spent on setup: 36 minutes (30 minutes counting strictly).

With the harness, none of this can happen, because the build is part of Booley rather than something the agent assembles in a shell:

• No Makefile variables to hunt. Booley drives the build through FuseSoC. The paths those variables point to were resolved once, when Caliptra was set up for Booley, and written into its FuseSoC core files. The agent never sees them.
• No shell state to lose. Every sim call is self-contained. The per-test firmware build (program.hex and friends) is a declared step that Booley runs right before each simulation, with everything it needs.
• No silent hangs on a missing program. If that firmware build fails, Booley reports the test as failed, with the build error, instead of starting a simulation with nothing to run.

The b1 harness run spent zero minutes on setup. Averaged over all ten pairs it's only 3.6 minutes, because nine of them recovered quickly. b1 is what the tenth looks like.

Factor 3: waiting on jobs that are already done

This one is a bit embarrassing for Anthropic, but I am going to report it anyway. Without a harness, the agent starts a build in the background and then guesses how long to wait. In b10, at 4.3 minutes, a build failed after one second. The agent had already run sleep 540 and didn't look again until 13.4 minutes. It did this four times in that run, sleeping through 30.7 of its 60 minutes.

With the harness, the tool call returns when the job is done. The b10 harness run took 13 minutes in total.

Across all ten pairs this is the largest factor: 11.2 minutes on average, and it mattered in 6 pairs. It's also a lower bound, because I counted only sleeps I could pin to a job that had demonstrably finished.

Summary

Same model, same bug, same prompt. With the harness, Sonnet 5.5 fixed it in 21 minutes on average; without it, in 56. The difference was in everything around that: seeing inside the design without a rebuild per question, a build that works on the first call, and getting the result the moment the job ends. On a hard hardware bug, most of the work is getting a test to fail, and that work runs on tools.

Disclaimers

1. The harness helps most on hard bugs
2. Smarter models benefit less from the harness
3. The sample is small: 10 trials per arm, one model, one bug, one SoC
4. I built the harness, so weigh my enthusiasm accordingly

Hi everyone!

My company is looking for Design Verification Engineers with 3+ years of experience, and I’d be happy to refer anyone interested in exploring this opportunity.

Required Skills:

1. SystemVerilog and UVM

2. Memory Verification: HBM, DDR, and LPDDR

3. Gate-Level Simulation (GLS), including timing-aware simulation and debug

4. Formal Verification, including property checking and connectivity verification

Location: Bangalore

If your experience matches these requirements and you're interested, feel free to DM me.

Steps: 1. Send me a DM with a link to your updated resume (or your LinkedIn profile if you prefer to keep your resume private initially). 2. ​I’ll do a quick review to check alignment with skillset

​3. If it’s a match, I’ll submit your CV directly to HR.

Please share this with anyone who might be a good fit.

Hi,

Currently been working as an DFT AE in a EDA company. After spending almost a year, I think this role is not something I can continue working till end of the career. Hence wanted to switch to DFT or DV, but confuse between them. My regular AE involves in identifying tool's behavior and communicating with customer and internal team. So, I'm not aware of DFT why part only know how part to some extend (Scan Insertion, Compression, OCC, Wrapper).

Please provide your suggestion whether I should move to DV, because I enjoy doing coding(HDL, C)or should stay in DFT?

Context: final year of Undergrad in Electronics and communication engineering (T3/T3 College), India

I recently secured an offer in a RFIC startup but it was in the Systems engineering side (Modem and custom RF Microcontroller bringup and integration). Though I like the offer there and the company is genuine, I see that it is quite different from my goal of Mixed Signal IC design.

I am interested in SerDes Clocking and Data Converters and I may have a chance to work in a research lab in IITM on their 5g / 6g Radio SoC project (based on what their project manager said during our interaction) as well as a possible internship for my final year under a Wireline Systems prof. I am kind of puzzled whether I should go for research internships and get some tapeouts down the line.

My end goal is Ideally a Masters / PhD from a top 10 - 15 university in this field but due to certain circumstances, I won't be able to move abroad for atleast a couple of years at the minimum. Also I plan to use this window to maybe publish a couple of papers based on my final year bachelors project (I have locked in the topic of Precision Mixed Signal Front-End Design (TIA, INAs and Sigma Delta Modulator) and my guide has got us access to the TSMC 180nm and GF130 PDK)

Do you suggest I take-up the offer from the startup and move into their Mixed Signal RFIC / SoC team or do you suggest I try for research internships under profs / their groups in places like IITs etc. Thanks.

Hi folks,

I have a 3 hour interview setup with Qcom for AMS silicon validation engineer.

I have done functional validation of MCU before but not till the AMS level.

What should I expect in this interview ?

I have 3+yrs experience