Verilog

In a Verilog question you write a hardware module. A read-only testbench drives it with inputs and prints the results. Your answer is correct when the printed output matches the expected output.

What you write and what you are givenCopy Anchor Link

• You write: the module, in main.v.
• You are given: a testbench in the Testbench tab of the console. You can read it but not change it.

How it runsCopy Anchor Link

Your code and the testbench are compiled together with Icarus Verilog (iverilog, Verilog-2005 with the SystemVerilog subset that Icarus supports) and then simulated. The testbench's top module is called tb.

The testbench:

• reads each test case's inputs from standard input,
• applies them to your module,
• prints what is graded with $display, and
• ends the simulation with $finish.

Your answer is graded by comparing what the testbench printed with the expected output.

LintCopy Anchor Link

Each time you run, Verilator also checks your own code and shows either Lint: no warnings or Lint warnings (verilator, not graded). Lint is advice, such as an unused signal or a width mismatch. It never affects your result.

WaveformsCopy Anchor Link

For sample cases a waveform is available so you can see your signals change over time. See Waveform viewer.

Writing Verilog that simulates wellCopy Anchor Link

• Match the module's name and port names to the question's statement exactly.
• Make sure the module can't loop forever. A simulation that never ends hits the time limit.
• Use non-blocking assignments (<=) in clocked blocks and blocking assignments (=) in combinational blocks.
• Give registers a defined starting value with a reset, since unknown values (x) can spoil an output.

What is not supportedCopy Anchor Link

• UVM and other advanced SystemVerilog verification features. Anything Icarus can't compile shows as a Compile error.
• VHDL.
• Checks based on the waveform itself. Grading uses the testbench's printed output.