Welcome to XCODX Online Compiler
Quick Start:
Ctrl+Enter Run code
Ctrl+S Save / Download
Ctrl+L Clear output
Select a language and start coding.
Icarus Verilog is an open-source compiler and simulator for Verilog, the hardware description language engineers use to design digital circuits. Steve Williams began the project in the late 1990s, and it implements the IEEE Verilog 1995, 2001, and 2005 standards along with parts of SystemVerilog. It helps to be precise about what this is: Verilog does not describe a program that runs top to bottom, it describes hardware — registers, wires, gates, and clocked logic whose parts all act at once — and Icarus compiles that description into a simulation you can run. The normal workflow is to write one or more design modules plus a testbench that applies stimulus, then watch how signals evolve over simulated time. It is widely used for coursework, FPGA and hobby projects, and as a free way to verify RTL before handing it to a synthesis tool. On XCODX your source is compiled with `iverilog` and run on the `vvp` engine inside a Piston sandbox, with the version shown in the badge above the editor.
// Design under test: a 4-bit adder
module adder(input [3:0] a, b, output [4:0] sum);
assign sum = a + b;
endmodule
// Testbench: drives inputs and prints the results
module tb;
reg [3:0] a, b;
wire [4:0] sum;
adder dut(a, b, sum);
initial begin
a = 4'd7; b = 4'd9; #1;
$display("%0d + %0d = %0d", a, b, sum);
a = 4'd3; b = 4'd4; #1;
$display("%0d + %0d = %0d", a, b, sum);
$finish;
end
endmoduleIcarus Verilog is for describing and verifying digital logic — adders, multiplexers, finite-state machines, bus protocols, and small CPU cores at the register-transfer level — and confirming they behave before synthesis. On XCODX you write the design plus a testbench, and system tasks such as `$display`, `$monitor`, and `$write` print signal values over simulated time; that text log is your output. It is simulation only: there is no synthesis to a real FPGA or ASIC and no bitstream, and the usual waveform viewer GTKWave is not available, so behavior is observed through printed messages rather than a waveform window. That makes it an excellent environment for learning Verilog, checking a module's logic, and working through HDLBits-style exercises, but not for programming a physical board.
Not in the everyday sense. Verilog is a hardware description language: your modules describe circuits whose signals all update concurrently, not a sequence of statements executed one after another. Icarus Verilog simulates that hardware over simulated time, which is why timing controls like `#delay` and `@(posedge clk)` matter as much as the logic itself.
A testbench is a top module, usually not synthesizable, that instantiates your design, drives its inputs from an `initial` or `always` block, and prints or checks the outputs. You generally need one, because a bare design module has nobody to supply its inputs — the testbench provides the stimulus and, importantly, the `$finish` that ends the run.
Use system tasks like `$display`, `$write`, and `$monitor` inside procedural blocks; their text goes to the run console. There is no waveform viewer in this sandbox, so those printed lines are how you inspect what the circuit did — `$display` prints once, while `$monitor` re-prints whenever a watched signal changes.
It can, but it rarely does, and that is normal for HDL. `$fscanf` can read from standard input and `$value$plusargs` can accept `+name=value` arguments, yet the overwhelmingly common practice is to hard-code stimulus inside the testbench's `initial` block. So on XCODX you usually set input values in the Verilog itself rather than typing them into the Stdin Box.
No. This environment only simulates; it does not synthesize to an FPGA or ASIC, produce a bitstream, or install extra tools, and GTKWave is not present. Your code can still write a `.vcd` file with `$dumpvars`, but there is no persistent filesystem or viewer to open it, so rely on `$display` and `$monitor` to observe behavior.
A design with a free-running clock or an `always` block can simulate forever, so you must call `$finish` (or `$stop`), usually from the testbench after enough simulated time — for example following a set number of clock edges or a `#100` delay. Without it the run simply continues until it hits the sandbox time limit.
main.vtext/x-verilogno standard input constructmodule main;
initial begin
$display("Hello from Verilog!");
$finish;
end
endmodule