Designing the logic that becomes a physical circuit, in an ASIC that is manufactured once and fixed forever or an FPGA that can be reprogrammed in seconds. The discipline is defined by two constraints software does not have: everything happens at once, and a mistake in silicon cannot be patched.
Assumes you know: Boolean algebra and binary arithmetic, What a flip-flop and a clock are, Willingness to think in parallel rather than in sequence, Any programming experience, mainly for the tooling around the work
Overview
What this area actually covers
Describing a digital circuit precisely enough that a tool chain can turn it into either a manufactured chip or a configuration for a programmable one, and then proving it behaves correctly before that becomes expensive.
The description is written in a hardware description language, usually at the register transfer level. That level names the storage elements in your design and the logic that computes what each one will hold after the next clock edge. It looks superficially like code, and the resemblance is the single biggest obstacle for newcomers, because nothing about it executes. There is no line that runs after another line. Everything you write exists simultaneously and is evaluated on every clock edge for as long as the part is powered.
Around that core sit the activities that make it real. Verification establishes that the design does what the specification says, and it is usually the largest single part of a project. Synthesis converts the description into a network of real logic cells. Physical implementation decides where every cell sits and how every wire runs, which is where a logical design acquires actual delay. Timing analysis checks that every path in the design completes within the clock period it was given. Test structures are added so that a manufactured part can be distinguished from a defective one. Each of those is a specialism in a large organisation and all of them in a small one.
The boundary with adjacent areas is worth drawing carefully, because job advertisements blur it constantly. This area is not electronics in the analogue sense: it is not about amplifiers, filters, power supplies, radio or sensor front ends, all of which are a different education and a different set of instincts. It is not board design, which is about choosing components, laying out a printed circuit board and getting signals between packages reliably. It is not embedded software, though embedded engineers and hardware designers work closely and often sit in the same team. And it is not computer architecture in the research sense of designing an instruction set or a cache hierarchy, although architecture decisions are what the RTL implements and a senior hardware engineer is expected to argue about them.
What people most often wrongly bundle in is the word "hardware" itself. In most software companies "hardware" means the machines you deploy onto. Here it means the logic inside a chip, and the people who do it are as far from a data centre technician as a compiler author is from someone who installs applications.
Now practise it
3 interview questions in Hardware & Silicon Design, each with the rubric the interviewer is scoring against.
This section currently has a single subsection, which reflects how tightly the discipline's interview questions cluster rather than any narrowness in the field.
Subsection
What it is for
ASIC/FPGA Design
Describing logic in an HDL, and making it meet timing on real hardware
ASIC/FPGA Design is the material that gets asked whether the role is an ASIC design role, an FPGA role, or a verification role that expects you to read the designer's work. It covers two things that are inseparable in practice. The first is the hardware description language itself, examined not as syntax but as a question about what a given description synthesises to: which lines become registers, which become combinational logic, and where a description accidentally creates storage you did not ask for. The second is timing and constraints, which is where the discipline's real difficulty lives: what setup and hold each require, how to read a slack figure, what to do about a violation and in what order, and why some paths must be told to the tool rather than discovered by it.
Sitting between those two is the topic that generates more interview questions per unit of code than anything else in the field: crossing a signal from one clock into another. A single flip-flop is not enough, the standard two-flop synchroniser solves exactly one of the three problems involved, and a multi-bit bus needs a mechanism of a different kind rather than a synchroniser per bit. It is a compact, deep subject with a wrong answer that seems obviously right, which makes it an interviewer's favourite.
You will find question pages there on all three of those threads, plus the commercial question that senior candidates are asked instead of a coding exercise: given this product, would you build an ASIC or use an FPGA, and what would change your mind. The fundamentals sheet for this section covers the surrounding vocabulary — the flow from RTL to a finished part, what verification actually consists of, where power goes, and how the round itself is usually structured.
Where it sits in a real system
Follow a function from a decision to a shipped part. Somebody decides that a piece of behaviour has to be in hardware, either because software cannot do it fast enough, or because doing it in software costs too much power, or because it must happen with a latency a processor cannot promise. That decision produces a specification: what the block does, what interfaces it speaks, how fast, and inside what power and area budget.
An engineer writes RTL implementing it. In parallel — and this is the ordering that surprises people — a verification engineer builds an environment that exercises that RTL against the same specification, deliberately without reading the implementation, so that a misunderstanding in one is not replicated in the other. When the two agree, the design goes through synthesis into a network of cells, then through physical implementation, then through timing sign-off, and eventually either becomes a mask set at a foundry or a bitstream loaded into an FPGA at power-up.
Loading diagram…
The edge worth looking at is the loop from the comparison back to the RTL, and the fact that the specification feeds two boxes rather than one. That double arrow is the whole reason verification is a separate role: its independence is what gives the comparison any value, and a verification environment written by the designer tests the design against the designer's own reading of the specification.
Once the part exists, it lives inside a product alongside things this discipline does not build. There is analogue circuitry converting between the physical world and digital signals. There is a board carrying power and connecting packages. There is firmware running on a processor, quite possibly one embedded in the same chip, driving registers that the hardware engineer defined. And there is a mechanical and thermal design that decides how much power the whole thing is allowed to dissipate, which is where an area and power budget originally comes from.
That surrounding context explains a habit of the discipline that looks like excessive formality from outside. Because a hardware block's interface is consumed by firmware written by other people, and because the block cannot be changed after manufacture, the register map and the protocol are specified in writing and reviewed before implementation rather than negotiated during it. The document is the contract, and it is a real one.
The two ideas that change how you think
Before any specific topic, there are two mental adjustments, and almost everybody arriving from software has to make both.
The first is simultaneity. In software, statements happen in order, and the order is the meaning. In an HDL, every construct you write is a piece of circuitry that exists and operates continuously and in parallel with all the others. Two assignments in the same clocked block do not happen one after the other; they happen at the same edge, and each reads the values that existed before the edge. A loop in your description does not iterate over time — it is unrolled into that many copies of the hardware. Cost, therefore, works in reverse: computing the same thing twice does not take twice as long, it takes twice the area, and reusing one piece of logic for two purposes saves area at the cost of needing a cycle to switch between them.
The second is that time is not free and not uniform. A signal takes real time to travel through gates and along wires, and the clock period has to be long enough for the slowest path in the design. This is the source of the discipline's characteristic activity: your design is functionally correct and the tool tells you a path needs more time than the clock allows, and now you have to restructure the logic, split it across two cycles, help the tool place it better, or slow the whole design down. Nothing in software prepares you for a correctness criterion that is about nanoseconds rather than about behaviour.
Loading diagram…
The item to look at is the fourth box's two incoming influences. The path's delay is only half the question; the other half is when the capturing clock arrives and how much of the period is lost to uncertainty in that arrival, which is why timing gets harder as a chip gets physically bigger even when the logic does not change.
Who does this work
The titles are more specialised than in software, and the specialisation is real rather than nominal.
Role
Owns
A day is mostly
Judged on
RTL design engineer
The description of a block's logic
Writing and reviewing HDL, debugging failures, arguing about interfaces
Whether the block is correct, meets timing, and fits its budget
Design verification engineer
The proof that the block is correct
Building test environments, writing checks, chasing coverage
Bugs found before manufacture, not after
FPGA engineer
A working programmed device
RTL, vendor blocks, board bring-up, integration with firmware
An RTL designer's day is less writing than reading and arguing. The writing itself is comparatively slow and comparatively small in volume, because each line is a piece of physical structure and the review standard is correspondingly high. The rest is debugging failures reported by verification, working out whether a timing violation is a constraint problem or a design problem, and negotiating interfaces with the blocks either side.
A verification engineer's day looks more like software engineering than the designer's does, because building a test environment is building a large piece of object-oriented code with generators, models and checkers. The skill is a different one: predicting how a design could be wrong, and constructing stimulus that would reveal it. In many organisations verification engineers outnumber designers, which is the most concrete evidence of where the effort actually goes.
The split that matters most for a newcomer is between the people who describe the logic and the people who make it physical. Front-end work — architecture, RTL, verification — is closer to what a software engineer recognises. Back-end work — floorplanning, clock trees, routing, timing sign-off, physical verification — is a genuinely different craft that involves running large implementation flows, interpreting their reports, and knowing what to change when a design will not close. Both are hardware engineering; someone strong at one is not automatically employable at the other.
FPGA work sits slightly apart because the loop is short. A change can be built and tried on real hardware the same day, which makes the work feel more iterative and puts the engineer closer to system integration and firmware. It is also the most accessible entry point, since the tools and boards are obtainable by an individual in a way an ASIC flow is not.
Demand, adoption and how that is changing
Demand is genuinely niche, and saying so is more useful than inflating it. The number of organisations that design their own chips is small compared with the number that write software, the teams are concentrated in a limited set of companies and a limited set of geographies, and the entry requirements are higher because the tools and the manufacturing are not accessible to an individual. Someone choosing a field on breadth of opportunity should not choose this one.
Niche is not the same as weak, though, and the specific shape of the demand is worth understanding. It is concentrated rather than scarce. Semiconductor companies, the large technology firms that now design their own silicon rather than buying it, networking and communications equipment vendors, automotive and industrial suppliers, aerospace and defence, medical devices, and financial firms building trading hardware all employ hardware designers, and within those employers the roles are steady and long-lived. Programmes run for years, so hiring is less volatile than in software, and turnover is lower. The pool of qualified candidates is also small, which is a real advantage once you are in it.
Two forces are increasing the work. The first is that general-purpose processors have stopped delivering the improvements that used to make custom hardware unnecessary, so functions that would once have been left in software are being built into silicon to get the performance or the power efficiency. That has pushed large organisations that had no silicon capability into acquiring one. The second is that machine learning workloads are unusually well suited to dedicated hardware, because the arithmetic is regular and the bottleneck is moving data rather than deciding what to do next, which is exactly the situation where a purpose-built data path beats a processor.
One force is reducing it, and it is worth being honest about. The one-off cost of an ASIC on a leading process is high enough that fewer organisations can contemplate one, so custom silicon is concentrating into large programmes at large companies while everyone else uses FPGAs or buys a standard part. That concentration is what makes the field's employer list short.
The tooling is also changing the character of the work rather than the amount of it. Higher-level synthesis, better verification automation and generation assistance have reduced the amount of hand-written description without touching the parts that are hard: deciding the architecture, deciding what to verify and knowing whether you have verified it, and closing timing on a design that will not close. Those are judgement, and judgement is what the interviews are structured to find.
What makes it hard
The defining difficulty is that you cannot patch it. A software defect found in production is a deployment. A defect found in a manufactured chip is a new revision: new masks, new wafers, months of delay, and the manufacturing set-up cost spent again. Every practice in the discipline is shaped by that asymmetry, which is why verification consumes more effort than design, why review standards look excessive, and why the decision to commit a design to manufacture is taken by a group rather than an engineer.
The second difficulty is that the failures are not reproducible in the way software failures are. A functional bug is comparatively pleasant: it happens for a specific input and you can simulate it. The characteristic hardware failure is a part that works on the bench and fails once an hour in the field, at a rate that changes with temperature and supply voltage. That signature points at a timing problem or a mishandled clock domain crossing rather than a logic error, and the reasoning that gets you there — a functional bug does not care about temperature — is the sort of thing experience supplies and reading does not.
Clock domain crossings deserve their own mention because they combine both difficulties. The failure is probabilistic. A flip-flop sampling a signal from an unrelated clock will occasionally sample it mid-transition and can hold an invalid level for an unbounded time, so the correct design does not eliminate the possibility but reduces its rate to something negligible over the part's life. That is an unfamiliar kind of correctness argument, it cannot be verified by running more tests, and the standard mechanisms each solve one specific part of the problem, so a design can use a synchroniser correctly and still be broken.
The third difficulty is that the abstractions leak downwards on purpose. In software, a working program is largely independent of where it runs. Here, the same description behaves differently depending on the cells available, where the tool put them, how long the wires turned out, how the clock is distributed, and what voltage and temperature the part is operating at. Physical reality is part of the correctness criterion, not an implementation detail, and that means a competent design engineer has to understand a fair amount about a stage of the flow they do not personally run.
And there is a slower difficulty that nothing substitutes for. Programmes are long. The gap between a design decision and the evidence about whether it was right can be a year or more, so the feedback loop that builds judgement in software over months takes years here. That is the main reason seniority in this field is not compressible, and why interviewers weight what you have seen a design do as heavily as what you know.
Why study it
Because it is the layer everything else stands on, and understanding it changes how you think about every layer above. Once you have designed a pipeline in logic, the reason a processor has one stops being a fact you memorised. Once you have watched a wire's length dominate a timing path, memory hierarchies and cache behaviour stop being arbitrary. Software engineers who have done hardware carry a durable intuition about what is cheap and what is expensive.
Because the skills depreciate slowly. Setup and hold, metastability, pipelining, the area-against-speed trade and the arithmetic of a timing path do not change with fashion. An engineer who learned these two decades ago still knows them, which is unusual and worth something in a career.
Because the pool is small. Fewer people can do this than can write applications, the training path is longer, and the employers who need it need it badly. Being one of a small number of people who can close timing on a difficult block is a different negotiating position from being one of many people who know a popular framework.
And because the constraint is satisfying in a way that is hard to convey. There is a specific pleasure in a discipline where a solution either fits in the cycle or does not, where you cannot talk your way around a number, and where the result is a physical object that does something.
Do not study it if you want breadth of employment, because the map of employers is short and geographically clustered. Do not study it if you want a fast feedback loop, because you will spend more time verifying than designing and more time waiting for a flow to finish than either. Do not study it as a route into embedded software, which is a different and much larger field you can enter directly. And do not study it if you dislike being wrong in a costly way, because the culture around review and sign-off is built precisely on the assumption that you will be.
Your first hour
Get a simulator and simulate one thing. There are freely available open-source Verilog simulators and waveform viewers, and you do not need a board, a vendor tool chain or a licence to start.
Write a module with a clock, a reset, and an eight-bit counter that increments when an enable input is high. Then write a testbench that generates a clock, holds reset for a few cycles, releases it, toggles the enable, and dumps a waveform. Open the waveform and look at it. That step is the point of the exercise: seeing values change on clock edges, and seeing what your reset actually did to the counter, converts the whole model from something you read about into something you have watched.
Then break it deliberately, three ways, because each break teaches one of the discipline's core lessons.
break what you should see
---------------------------------------- -------------------------------------------
remove the reset from the testbench the counter starts from an unknown value
change the sequential block to use = the pipeline collapses into one cycle
add a condition with no else branch a lint or synthesis warning about a latch
The first break shows you why initialisation is a design decision rather than a detail, and why an FPGA — whose registers come up at values loaded from the bitstream — can hide a bug that an ASIC will not. The second shows you why the choice of assignment operator in a clocked block is a rule and not a preference, since the same three lines describe either a three-stage shift register or a wire depending on which one you used. The third shows you the most common accidental defect in the language: a combinational block that does not assign an output on every path is asking for storage, and you get it.
Then, if you want to go one step further in the same sitting, add a second clock to the testbench with an unrelated period, drive a signal from one domain into a flip-flop clocked by the other, and watch what happens at the boundary. A simulator will not show you metastability, because it has no way to represent it, and noticing that limitation is itself the lesson: the failure mode that dominates this discipline is one your primary tool cannot reproduce.
The artefact at the end of the hour is a waveform you can read and four sentences you can write: what your registers hold before reset is released, how many cycles a value takes to travel through your design, which of your blocks are combinational and which are sequential, and where in your design a signal changes clock. Those four sentences are approximately the opening five minutes of a hardware interview.
What this is not
It is not electronics. Analogue and radio-frequency design, power conversion and sensor interfacing share a department and almost nothing else: different mathematics, different tools, different instincts. A digital designer who claims analogue competence is quickly found out and vice versa.
It is not embedded software. Embedded engineers write the firmware that drives the registers a hardware engineer defined, and the two roles collaborate closely and are frequently advertised under overlapping titles, but writing C for a microcontroller is not designing the microcontroller.
It is not board design. Choosing components, laying out a printed circuit board, managing signal integrity between packages and getting power distributed cleanly is its own discipline with its own tools, and it is what many people mean when they say hardware.
It is not learning a language. Verilog and VHDL are small languages and their syntax is the least of the difficulty. Someone who has memorised the syntax and cannot say what a given block synthesises to has not started, which is why interviews consistently ask what a snippet becomes rather than asking you to write something.
It is not a choice between ASIC and FPGA that you have to make before learning anything. The description language, the verification thinking, the timing concepts and the crossing mechanisms are shared, and the differences appear at the edges: which library blocks you instantiate, whether registers have a known value at power-up, and what happens when you get something wrong. Starting on an FPGA because it is accessible costs you nothing if you eventually move.
And it is not immune to the software industry's habits of thought, but it is unusually resistant to them. Move fast and fix it later is not a strategy available to a discipline where fixing it later means new masks, and understanding why that is true is most of understanding the culture of the field.
Every practice in this discipline — the verification effort, the review standards, the formality of an interface document — follows from one fact: the thing you are building cannot be changed once it has been manufactured.