Report a problem

What to report

• A wrong claim. A lesson, quiz explanation or problem statement says something about SystemVerilog, UVM or a simulator that you believe is false.
• A broken problem. Correct code is rejected, wrong code is accepted, a test checks something the statement never asked for, or the page will not run.
• An unclear lesson. A paragraph you had to read three times, a term used before it was defined, or an example whose output you could not explain.
• A simulator difference that Simulators and known differences does not list.

Small reports matter as much as large ones. A typo in a signal name can cost a reader ten minutes.

What to include

1. The page

   The address of the page, and the lesson or problem number, such as lesson 3.3 or problem 2.7.8.

2. What you expected

   What you thought should happen, and why. If you are quoting the standard, give the IEEE 1800-2017 or 1800.2 clause number.

3. What happened

   What the page or the simulator did instead. For a problem, say whether you ran the samples or submitted.

4. The code and the output

   The smallest code that shows it, and the simulator's output copied as text, including the simulator name shown on the page. A screenshot of a waveform helps for timing questions.

For example:

Page:      lesson 2.2, Queues and ordering
Expected:  pop_front on an empty int queue returns 0
           (IEEE 1800-2017, queue methods)
Happened:  the quiz explanation says it returns x
Code:      int q[$]; initial $display("%0d", q.pop_front());
Output:    0   (Verilator 5.052, from the lesson's Run button)

Please leave out personal or company information that the report does not need, such as proprietary code. A short example that shows the same behaviour is always better.

Where to send it

Send reports to [email protected].

The site does not watch what you do on its pages, so a report is the only way it learns that something is wrong. Requests about your account or your data go to the same address (see the privacy notice).

What happens next

Each report is checked the same way the content was written: against the standard first, then by running the code on the simulator the page uses.

• If the page is wrong, it is corrected, and the checks that every lesson and problem must pass are run again before it goes back up.
• If a problem accepted wrong code, the missing case is added to its hidden tests, and the problem is qualified again. See How problems are graded.
• If the simulator departs from the standard, the difference is added to the simulators page and noted in the lesson.
• If the page turns out to be right, it may still be reworded, because a page that misleads a careful reader needs fixing too.