About ASIC Point

What it is

ASIC Point is a free course in design verification (DV), the work of proving that a chip design does what its specification says. It covers SystemVerilog for testbenches, UVM, assertions and functional coverage.

Each lesson starts from a failure a verification engineer would recognise, shows it in a waveform or a log, and explains the language rule behind it. Every lesson has a runnable example, a short quiz and links to practice problems.

The problems are graded by running your code on a real simulator. Some ask you to write a design or a model. Others ask you to write the checker, and grade it by the bugs it catches.

Who it is for

• Job seekers preparing for DV interviews, who need practice that behaves like real work rather than trivia.
• Working DV engineers who want to check a language detail, or practise a part of the job they rarely touch, such as assertions or coverage.
• University courses that need lessons and graded exercises students can use without licences or installs.
• Company training teams onboarding new engineers, who need material whose answers have been checked on a simulator.

The lessons assume basic digital logic and some Verilog or VHDL. They do not assume prior SystemVerilog or verification experience.

What is different here

These are the practices the site follows. Scripts check the first two, and a lesson or problem is marked ready only after it passes them.

• Runnable claims are run. Every lesson example, every predict-the-output answer and every spot-the-bug option is executed on a real simulator, and the page is rejected if the output differs. Multiple-choice and waveform questions are reviewed by hand.
• Problems are qualified against named mutants. A mutant is a named, realistic wrong version of the answer. A problem is published only when its reference solution passes, its starter code fails, and every mutant fails for the reason it declares.
• Five problem formats. Besides writing code (Implement) and repairing it (Fix), you can write a checker graded by the faulty designs it catches (Verify). You can also write stimulus that exposes hidden bugs (Break it), and find a bug from a waveform (Debug). See How problems are graded.
• Simulator differences are published. Where a simulator departs from the IEEE standard, the lesson says so in a Simulator note, and the full list is on Simulators and known differences.

What is free

Everything: every lesson, every problem, the simulators in the browser and the grading. There are no adverts and no paid tier. Lessons, the playground and the open problems need no account; a free Google sign-in opens the rest of Bug Hunt and a skill rating.

Your code drafts and quiz progress are saved in your own browser. When a lesson or problem runs on the simulator server, your code is sent there to be compiled and run.

How content is checked

A statement in a lesson has to survive three checks, in this order.

1. The standard

   IEEE 1800-2017 for SystemVerilog and IEEE 1800.2 for UVM decide what the language and the library do. Each lesson keeps a list of its claims with the clause that supports them.

2. Reference books

   Established SystemVerilog, assertion and UVM texts are used to cross-check explanations and common practice. They are used for checking only; no text is copied from them.

3. Simulation

   Any claim that can run, runs. Examples, predicted outputs and spot-the-bug options are executed on the simulator the lesson names, and the build fails if any result changes.

When the standard and a simulator disagree, the lesson teaches the standard and states what the simulator does instead. Runnable code is kept to the parts both agree on.

Lessons also follow a written style guide: short sentences, every term defined on first use, and at least one waveform, table or diagram per lesson.

What is planned

The SystemVerilog modules and the Assertions track are written to this standard. The coverage and UVM tracks are being rewritten to it now.

• Design track (planned): writing RTL that is easy to verify, using the same simulators and problem formats.
• Physical design (planned, later).
• Analog and SPICE (planned, later).

Found a mistake? See Report a problem.