The Problem Behind the Validation Problem: What Engineers Between the Silos Are Telling Us

WATCHTOWER BRIEF · EDA 3.0 · VERIFICATION

A VIEW FROM THE WATCHTOWER · PART 2 OF “THE END OF EDA?”

The vendors are building agents. The engineers who validate the silicon are on Reddit asking how to get out. Read their complaints as symptoms rather than verdicts, and a different problem appears: narrow jobs carrying broad accountability.

In The End of EDA? I argued that the center of gravity in electronic design automation is shifting from engineering tools toward engineering intelligence, and that what falls between the silos may become more valuable than what happens inside them. That piece was written from the top down: press releases, partnerships, investor days.

This one is written from the bottom up. If the value is moving into the gaps between disciplines, the people who already live in those gaps should have something to tell us. In semiconductor development, that is very often the verification and validation engineer.

So I went looking for what they say when no vendor is listening.

What are chip validation engineers saying on Reddit?

Spend time on r/chipdesign and a pattern is hard to miss. Engineers in post-silicon validation and pre-silicon design verification regularly ask how to move into design, and some who made the move reply with their stories. Threads such as “Moving from validation to design or verification” and “Design Verification to Design” are typical of the genre. There is even a rebuttal to the genre itself: “Validation engineering is only a trap if you let it be”.

A word on method before going further. This is a qualitative read of 12 r/chipdesign threads posted between February 2024 and September 2026, holding roughly 330 comments between them and ranging from a handful of replies to more than 80. They were selected for relevance, not sampled at random. Posters are anonymous and their histories unverified; two of the threads were started by the same person, and a couple of posts were accused by other readers of being AI-written. Anyone searching for unhappy engineers will find them. What these threads can do is show recurring experiences and plausible mechanisms. They cannot tell us how widespread dissatisfaction is or whether it is getting worse.

It also matters that two different jobs share these threads. Post-silicon validation is lab work, characterization, bring-up and scripting. Pre-silicon verification is testbenches, UVM, coverage and RTL debug. Both produce “how do I move into design?” posts, but the frustrations and the exits differ.

To read the complaints, I borrowed the lens my co-founder John Simmons sets out in his book, The Problem Behind the Problem: treat what someone says hurts as a symptom, and keep asking until you reach the condition that produces it. Five complaints come up again and again.

Is validation really repetitive, or is it execution without influence?

The most useful thread for this question is the one defending validation. In “Validation engineering is only a trap if you let it be”, the author describes validation as widely seen as a cost center: at the tail end of the schedule, with little control over what it is handed, very execution-heavy, and able to leave you without a system-level understanding of the chip. They still call it one of the best places for a young engineer to start. One respondent with 15 years in system and validation roles contrasts two employers: one where the job was to run a huge list of tests quickly while nobody looked at the results, and another where system validation led and oriented the design.

The OP (original poster) of “Design Verification to Design” offers a smaller version of the same insight. After a year in verification, they find completing testcases boring, then volunteer a likely reason: their scoreboarding is weak and they are updating tests by hand. The complaint is about the work; the cause they name is the method.

Same discipline, very different jobs. Read through the PBP lens, “I dislike validation” can mean “my organization uses my technical skills mainly to execute instructions.” That distinction matters, because faster execution does nothing for someone whose real problem is a lack of influence on decisions.

Is the problem specialization, or experience that does not travel?

In “What's one mistake you made early in chip design?”, one commenter describes becoming highly specialized at a large company with little exposure outside their domain, while others credit smaller companies with giving them breadth. The replies push back usefully: some large companies expect contributions from architecture through post-silicon debug, and offer access to experts and training that startups cannot. The variable is organizational practice more than company size.

The 15-year respondent in “Validation engineering is only a trap if you let it be” names what actually locks people in: salary expectations against experience. As pay rises with seniority, it becomes cheaper for an employer to hire a junior person into a new role than to move an experienced engineer into a field where they have no track record. The original poster agrees that repositioning away from a label others attach to you is brutal.

The career-transition threads add the cost side. In “Moving from validation to design or verification”, a respondent who started in post-silicon validation describes moving into design after seven years. It took two changes of company and turning down a promotion to senior validation engineer at a tier 1 "FAANG" company to start in design at entry level, and they caution that switching does not guarantee happiness. Another engineer in the same thread, still in post-silicon validation, says they keep being rejected for lacking experience in the exact domain. That is a handful of accounts, not a typical price, but it explains why a technically demanding role can still feel like a trap: expertise deepens while the options outside it narrow.

Is verification getting too hard, or is the feedback loop too slow?

In “Verification strategy for very large SoC”, engineers describe the standard response to scale: verify heavily at block and subsystem level, then run expensive system tests. Respondents describe full-chip simulations measured in days; the author notes that a CPU configuring the chip can burn two milliseconds of simulated time, roughly a day of wall-clock time, before a test does anything useful. And the author makes a sharp point. When dozens of tests are failing, the time goes into debugging, so running tests faster would not make much of a difference.

One respondent who has done verification for a couple of decades puts the integration problem plainly: a large share of SoC work is plumbing, making sure the software level is correctly connected to the hardware level. That is work that lives between teams by definition.

An adjacent thread from physical design shows the mechanism clearly. In “Physical design engineer who is tired of work pressure”, the author's initial complaint about changing targets and bookkeeping narrows, in follow-up, to something more specific: running tools and debugging without a clear view of what the RTL team intended. One respondent describes embedding a physical-design engineer with the RTL team for exactly that reason.

What about chiplets? The technical case that disaggregation adds verification and debug burden is well established outside Reddit. The UCIe 2.0 specification added a dedicated architecture for test, telemetry and debug across the chiplets in a package, from sort through to the field, precisely because cross-die observability does not come for free. But within this set of threads, nobody compares otherwise similar monolithic and chiplet programs. The honest conclusion is that system integration is a visible concern, and chiplet-specific attribution remains weak.

Is AI helping verification engineers, or adding work?

The firsthand AI accounts are more interesting than the predictions, because almost every one reports both.

These are self-reported episodes with different tasks, baselines and users, so the numbers should not be averaged into a productivity claim. The pattern is the useful part:

And it fails in the same place the engineer does. Where the relevant specification, vendor detail or firmware assumption is unavailable, fluent output cannot establish that behavior is correct. “We need better AI” can conceal “our engineering information is hard to find, interpret and connect,” though bad prompting and plain wrong reasoning remain competing explanations.

Is moving into design an escape?

Not reliably. A useful counterexample runs the other way. In “Design/arch to post silicon validation”, an engineer doing front-end design and architecture on memory controllers describes a team so toxic they had been in tears daily for months, and is weighing a post-silicon validation role at a company with better pay and work-life balance. A respondent who has worked on both sides says validation experience feeds back into design. A move into design usually changes the team and often the company too, so when someone reports being happier afterward, Reddit rarely gives us enough to tell which change made the difference.

The tooling debates show the same need for diagnosis. In “Chip designers: ever feel like our tools are stuck in the past?”, complaints about usability and slow feedback meet respondents who would rather have reliable batch operation and closure than a nicer GUI. One experienced verification engineer says their biggest problems do not come from the EDA tools at all; what would help most is five more people. “Our tools are bad” might mean usability, integration, reliability, methodology or simply unfamiliarity with what the tools can already do. Each needs a different fix.

What is the problem behind the validation problem?

Put the threads side by side and the stated complaints map onto underlying conditions that could be tested.

If there is one hypothesis that ties these together, it is this: some verification and validation engineers are accountable for system correctness without enough access to the information, observability and decision authority needed to establish it. That would explain how a job can feel narrow and overwhelming at the same time. It is a hypothesis to test, not a finding, and capacity, methodology, management and plain career fit remain competing explanations.

What should engineering leaders measure instead?

More complaints will not settle this. A single, well-documented failure will tell us more than another hundred threads. Take one recently resolved integration failure and reconstruct it end to end:

Then split the elapsed time into four buckets: reproducing the failure, obtaining the right information, agreeing who owns it, and proving the fix. Most organizations measure the first and guess at the rest. That split, more than any tool benchmark, shows whether the constraint is compute, methodology, information or organization.

What does this mean for EDA 3.0?

The vendor announcements in part one are mostly about making each task faster and more autonomous. The engineers in these threads are describing a different bottleneck: local automation is improving faster than shared understanding of the whole system.

Faster test creation helps. The larger opportunity is connecting requirements, interface assumptions, configurations, verification results and silicon evidence, so that someone can answer three questions quickly: what failed, under which conditions, and who owns the explanation. That is the engineering provenance argument from part one, seen from the lab bench rather than the investor day. It is also the core of EDA 3.0.

Reddit does not prove that disaggregation has made validation unmanageable, or that AI is making the job worse. It does make a strong case for asking better questions before buying another faster tool.

Frequently asked questions

Why do validation engineers want to move into design?

In r/chipdesign threads, the recurring reasons are limited ownership of the outcome, repetitive execution work and fear that validation experience will not count toward design roles. Counter-threads defend validation as deep technical work, and some engineers move the other way, so the pattern reflects how roles are structured more than the discipline itself.

What is the difference between pre-silicon verification and post-silicon validation?

Pre-silicon design verification checks RTL against its specification using testbenches, UVM, coverage and simulation before tapeout. Post-silicon validation tests real silicon in the lab through bring-up, characterization and system-level testing. Both involve finding failures, but the tools, constraints and career paths differ.

Do chiplets make verification and validation harder?

Chiplets add interfaces across which assumptions and evidence must travel, which is why UCIe 2.0 added a standard architecture for test, telemetry and debug across chiplets. Practitioner discussion on Reddit, however, does not isolate chiplets as the main cause of validation engineers' frustration.

Is AI helping chip verification engineers?

Firsthand accounts on r/chipdesign report both real acceleration on testbench, scripting and documentation work and costly errors, such as unchecked assumptions or incorrect diagnoses. AI tends to help most where engineers can supply complete context and check the output.

What is the problem behind the problem method?

It is a discovery approach developed by John Simmons, co-founder of AiT, and set out in his book of the same name. It treats a stated pain as a symptom and works through Reveal, Diagnose, Expand, Qualify and Advance to reach the underlying condition before proposing a solution.

If you lead a verification or validation team and have a failure story you would be willing to walk through, I would like to hear it. Reach me directly at simon@ai-techsales.com.

Simon Bennett is CSO and Co-Founder, AiT, and founder of Kite SOC LLC. He has more than 40 years of experience in EDA and semiconductor IP, at both EDA companies and semiconductor design companies.

FURTHER READING ON THE WATCHTOWER BRIEF

Sources: r/chipdesign threads Validation engineering is only a trap if you let it be; Moving from validation to design or verification; Design Verification to Design; What's one mistake you made early in chip design?; Verification strategy for very large SoC; Physical design engineer who is tired of work pressure; Chip designers: ever feel like our tools are stuck in the past?; Design/arch to post silicon validation; My personal experience with AI in ASIC verification; AI in chip design (again); Claude Code vs chip design specialized AI tools; AI has made the lives of chip designers harder; UCIe Consortium, UCIe 2.0 specification and white paper. Paraphrases were checked against saved copies of each thread on October 23, 2026. Reddit posters are anonymous and their accounts unverified; they describe individual experiences, not industry-wide data.