RTL, verification or physical design: choosing your VLSI path

On 13 October 2026, HireSetu had 480 published listings that carried the employer's own job text. Fifty three of them were tagged semiconductor or VLSI. That tag is looser than it sounds. It also covers software and firmware roles inside chip companies, so it overstates the number of core chip design jobs.

Narrow it to titles that name a digital chip design function and the count falls to 13: five design verification roles (Cadence, NVIDIA, Texas Instruments twice, AMD), five physical design roles (Synopsys, Qualcomm twice, Arm, Texas Instruments) and three RTL or digital design roles (AMD, Tesla as a graduate intern role, Texas Instruments). These figures describe HireSetu's curated entry-level listings on that date. They say nothing about the whole job market, and one day's snapshot is not a trend.

What the snapshot gives you is proportion. If you cannot answer which role you are preparing for, more tool names will not help. You need a way to decide: the question each role asks, one week spent trying each, and a score sheet you fill in yourself.

The three roles side by side

RTL design, from the traffic light's side

Take a traffic light controller: four roads, timers, a pedestrian button, a reset. The RTL engineer describes that machine in synthesizable Verilog or SystemVerilog so the description matches both the spec and the intent. Which state are we in, what moves us out of it, what happens when reset arrives halfway through a green phase, what happens if the timer input jumps by an odd value because the counter upstream was written carelessly.

The work is mostly not typing. You turn ambiguous sentences into a state machine, decide the clocking and reset scheme, decide where registers sit, and defend all of it in a review. Lint and synthesis are the first honest feedback you get. An inferred latch or a width mismatch warning means your description and the hardware disagree.

The learning path that holds up: get digital logic right first, meaning flip-flops, counters, FSM design, metastability and synchronisers. Then write small modules with a testbench each. A counter, a sequence detector, a FIFO, a round-robin arbiter. Learn what synthesis infers from your coding style by reading the synthesis log, not a tutorial. When you can look at a block of Verilog and say what hardware it becomes, roughly how many flops, you are ready to talk to interviewers.

Design verification, from the traffic light's side

Same controller, different question. The verification engineer has to find where it breaks. The normal sequence of green, amber, red passes on the first run, which tells you almost nothing. What if reset is asserted exactly as the amber timer expires? What if the pedestrian button is pressed twice in the same cycle? What if two roads request priority together?

A testbench that prints PASS is not verification. A test plan mapped to requirements, directed tests for the corner cases, a checker that compares behaviour against a reference model, assertions on protocol rules, and coverage that tells you which parts of the design were never exercised. UVM is what many teams use daily, and it is worth learning, but a fresher who can write a clear test plan and a self-checking testbench beats one who has memorised the UVM phases.

Project worth doing properly: verify a synchronous FIFO. Cover empty and full flags at the boundaries, data ordering, simultaneous read and write, and reset at awkward moments. Link every test to a line in a requirement list. Then plant a bug in the RTL, change a pointer increment, flip a flag condition, and show which test catches it. Learn to write a bug report that states the conditions, the expected behaviour, what you observed, and the shortest way to reproduce it. That report is the real deliverable of the job.

Physical design, from the traffic light's side

The same controller, now as a netlist that has to become silicon. Someone decides where the standard cells sit, how power is distributed, where the clock tree goes, how hundreds of signal nets route without blocking each other, and whether timing closes at all.

The daily loop is reading reports and making trade-offs. A path misses setup by 40 ps, so you upsize a cell or move it closer to its neighbour. Timing improves, area and leakage go up, and a different path may get worse. Hold violations appear after clock tree synthesis and need fixing without wrecking setup. Congestion shows up in one corner of the floorplan and forces a block to move. Every fix costs something elsewhere.

The fundamentals that carry you here are static timing analysis: what a path is, what slack means, setup and hold, and how constraints describe the clock and the interfaces. If commercial tools are out of reach, run an open-source flow such as OpenLane or OpenROAD with Yosys on a small block and read the reports with help. Say plainly in interviews that it was an open-source flow. Nobody expects a student to own a Synopsys licence, and pretending otherwise collapses under two follow-up questions.

Three one-week trials

1. Week 1: RTL

   Pick one block, a traffic light controller or an arbiter. Write it in synthesizable Verilog, write your own testbench, synthesise it if a tool is available and read every warning. Notice whether you enjoy the moment the FSM finally behaves, and whether you care why the synthesis log complained.

2. Week 2: Verification

   Take the same block, or a FIFO, and write the test plan before any code. Add directed tests, a self-checking testbench and two or three assertions. Then break the RTL deliberately and confirm your tests catch it. Notice whether hunting the failure feels like a puzzle or like a chore.

3. Week 3: Physical design

   Start with reading, not tools. Read one implementation flow end to end (floorplan, power plan, placement, CTS, route, signoff), then run a small open-source flow and open the timing report. Pick three failing paths and explain in plain words why each one fails. Notice whether the report reads like a puzzle or like noise.

What scripting showed up, and what it means

Across those 53 semiconductor and VLSI listings, the employer text mentioned Python in 17, Perl or Tcl in 15, Linux or Unix in 13, Verilog in 13, SystemVerilog in 4, UVM in 2 and static timing analysis in 2. Same caveat: this is HireSetu's curated entry-level set on 13 October 2026, not the market.

Two things follow. Scripting and the Linux command line appear roughly as often as Verilog, and far more often than UVM. That matches how the work runs. A test that takes an hour to set up by hand gets scripted or it never runs again. A timing fix gets applied across fifty paths by a Tcl script, not by hand. The second point: none of the 53 listings asked for a certificate from a training course. Employers asked for degrees and skills, not course brands.

UVM is still worth your time if verification is where you land. The order matters though. Python, Tcl or Perl plus comfort on Linux pays off in every path and every internship. UVM pays off in one path, later, and mostly after you can already write a self-checking testbench without a framework.

Scoring the three paths

Score each path from 1 to 5, one sentence per score

• Interest: how much you want to keep working on this problem after the novelty fades, not how impressive the role sounds to relatives.
• Comfort with fundamentals: digital logic for RTL and verification, STA and timing for physical design. Score what you can do today, not what you plan to learn.
• Willingness to debug: verification and physical design are long debugging loops. If a failing test at midnight drains you, write that down honestly.
• Access to tools: a laptop with open-source tools, a college lab, or a paid cloud licence all score differently. Rate what you can reach this month.
• Match with verified entry-level openings: use real listings you have read, separating 0 to 2 year roles from 3 plus roles. Twenty to thirty listings per role is enough to see the pattern.
• Write one sentence beside each score saying why. Then total. A path that wins on interest and access and loses slightly on openings is a better bet than one that wins only on pay.

Questions worth asking a working engineer

Ask people who do the job, and ask specifics. General questions get general answers.

• What did you do in your first six months, week to week?
• Which fundamentals do you use every week, and which ones did you forget after training?
• What does a good bug report look like on your team? Can you show me one?
• When did you last have to send something back to the RTL owner or the constraints writer, and what was it?
• What would you expect a fresher in this role to have built before joining?
• How much of your week is scripting and reading reports versus the work the role is named after?