In the fast-moving business of chip design, where logic and silicon come together to power the devices we rely on every day, a group of quiet problem solvers does the careful work behind the scenes: ASIC verification engineers. These are the people who chase down bugs before a chip ever reaches production, testing every path…
In short: Designs need many clock frequencies from one reference. Division is simple but only gives integer ratios below the reference and can pile up jitter across a long chain. Multiplication, usually via a PLL, reaches higher frequencies, supports non-integer ratios, and often has lower jitter, which is why it suits high-speed links, CPU cores,…
In short: Formal and functional verification are partners. Formal uses mathematics to prove a property holds for every possible case, which fits small control logic and safety-critical corners. Functional runs simulations across many realistic scenarios and scales to a full system, but it can only sample the state space. Strong teams use formal for the…
In short: Debugging carries a scientific name, but the toughest failures are cracked by judgment, not formulas. You follow clues like a detective, lean on experience to sense where a bug hides, invent unplanned stress cases, and talk the problem through with your team. The rigorous side confirms a cause; the artistic side is what…
In short: Good verification is less about tools and more about how you think. Five habits carry most of the weight: thinking strategically about the whole system, reading the design the way its author did, inventing test cases that push past the happy path, choosing the right method for each job, and sharing what you…
In short: This is a set of the most common coverage interview questions with clear, LRM-correct answers: code vs functional coverage, the code-coverage types, what high-one-low-other numbers mean, covergroups vs cover properties, coverpoints and bins, ignore vs illegal bins, transition and wildcard bins, cross coverage, and the two ways to sample a covergroup. Coverage comes…
In short: Good functional coverage guidelines keep your coverage honest and useful. The essentials: base coverage on the test plan and the spec, keep a traceability link from each scenario to a cover point, add controls to enable or disable coverage, turn coverage on after the early bug storm settles, collect coverage only from passing…
In short: There are two families of coverage metrics. Code coverage is measured automatically by the simulator and tells you how much of the RTL was exercised (statement, block, branch, condition or expression, toggle, and FSM). Functional coverage is written by you and tells you whether the features from the test plan were actually tested….
In short: Functional coverage options in SystemVerilog tune how a covergroup collects and reports data. The everyday ones are option.comment to label a group, option.per_instance to report each instance separately, option.at_least to set how many hits a bin needs, option.cross_num_print_missing to show empty bins, and option.goal to set the target percentage. They change reporting, not…