The Actual Workflow Nobody Tells You About
Most tutorials skip straight to writing code and hope it synthesizes. That never works on the first try. You write the code, simulate it, then figure out why the simulation looks nothing like what you intended. I spent about three weeks circling back to this before I stopped fighting the toolchain and started reading the error messages properly. Here is how you actually go from a blank editor to a working logic circuit. Start by defining what you want the circuit to do in plain English. Not pseudocode. A sentence like "this circuit takes a 4-bit binary number and outputs its one's complement." That specificity matters because the first failure most people hit is writing VHDL that is syntactically correct but semantically wrong for the hardware you are describing.
Introduction To Logic Circuits Logic Design With Vhdl
VHDL is a hardware description language. That means it describes circuits, not programs. When you write a process block with a sensitivity list, you are not writing something that runs sequentially like Python. You are declaring what gates and registers should exist, and when they update. This distinction gets people immediately wrong. I wrote a synchronous counter once that looked perfect in simulation but synthesized into a latch because I forgot to assign a signal in every branch of an if statement. The compiler tried to infer memory where I only wanted combinational logic. So here is the actual sequence you should follow. Open your tool of choice. I used Quartus Prime Lite and ModelSim Starter Edition, though Icarus Verilog with GTKWave works fine if you are doing smaller designs. I prefer the Xilinx Vivado flow for anything that needs to target actual FPGA hardware. The exact tool does not change the concepts, but the error output varies enough that sticking to one helps. Create a new project. Select your target device. If you are learning, pick whatever evaluation board or basic FPGA you have access to. Do not pick a high-end Artix-7 just because it is powerful. The timing reports will eat your weekends for no reason. A Cyclone IV or a Spartan-6 is plenty for learning. Set the HDL file type to VHDL and add a new source file.
Write the entity declaration first. This is the port list. It defines inputs and outputs. Every signal that goes in or out of your circuit must appear here. Missing a port is the simplest way to get a synthesis error that looks completely unrelated to the actual problem.
Get the Full Details
entity example_circuit is
port (
clock : in std_logic;
reset : in std_logic;
input_data : in std_logic_vector(3 downto 0);
output_data : out std_logic_vector(3 downto 0)
);
end entity;Then write the architecture body. This is where the actual logic lives. For a beginner, the behavioral style is fine. You can always move to structural if you need hierarchy. Write concurrent signal assignments for simple combinational logic. Use process blocks with clock edges for sequential logic. Keep them separate. Mixing them in one process causes confusion that lingers for months. For simulation, write a testbench. This is not optional. Simulating without a testbench means you are debugging by guessing. A proper testbench applies stimulus and checks the outputs. I used to skip this step until I spent four hours chasing a metastability issue that a properly written testbench would have caught in under two minutes. Here is a testbench skeleton I come back to every time:
architecture tb of example_circuit_tb is
signal clock : std_logic := '0';
signal reset : std_logic := '0';
signal input_data : std_logic_vector(3 downto 0) := (others => '0');
signal output_data : std_logic_vector(3 downto 0);
begin
uut: entity work.example_circuit
port map(clock, reset, input_data, output_data);
clock_process: process
begin
clock <= '0';
wait for 5 ns;
clock <= '1';
wait for 5 ns;
end process;
stimulus_process: process
begin
reset <= '1';
wait for 20 ns;
reset <= '0';
input_data = "0000";
wait for 10 ns;
-- add more stimulus here
wait;
end process;
end architecture;Run the simulation. Watch the waveform. If your output is X or U everywhere, your reset is probably not initialized correctly. If the output is stuck at zero, your clock edge detection is wrong or your process sensitivity list is missing the clock signal. These are the first three errors you will see, and they are the first three you will make. Once the simulation passes, run synthesis. This converts your VHDL into a netlist of logic gates. The synthesis log tells you whether your design is too wide, too deep, or has inferred latches. If it says inferred latch, go back and fix the incomplete assignment. If it says timing violation, that is a different problem entirely. Here is where the practical trap is. Simulation and synthesis are not the same thing. Simulation is event-driven and ignores propagation delay. Synthesis cares about everything. A multiplexer expressed as a large case statement inside a process simulates fine and may synthesize into a mess of cascaded MUXes that fail timing. Writing a generate statement instead or using selected signal assignment with when else keeps the structure cleaner and the timing report happier.
I ran into a specific problem last year where a state machine I wrote worked perfectly in simulation but produced incorrect output after programming onto a board. The issue was that I had used a single process for both state transition and output logic, which made the outputs depend on the old state until the clock edge fired. Splitting the output logic into a separate process and registering it eliminated the glitch. That took me about six hours to diagnose. The simulation waveform had looked identical either way because simulation does not model glitch behavior by default unless you enable it, which turns your simulation times from seconds into minutes for anything non-trivial. For learning logic circuits, start with small examples. A half adder. A full adder. A 4-to-1 multiplexer. Then combine them into something like a 4-bit adder with carry. Each of these teaches a specific VHDL construct. Half adder teaches concurrent assignment. Full adder teaches component instantiation. The multiplexer teaches selected signal assignment. The 4-bit adder teaches you how to handle carry chains and why you should use the std_unsigned or numeric_std package consistently from the start. Do not mix std_logic_arith or std_logic_unsigned. Those are not standard and they behave inconsistently across tools. numeric_std is the IEEE standard. It is slower to type because you have to convert explicitly, but it does exactly what you expect. The extra typing prevents the subtle bugs where one tool interprets a signed operation differently than another.
When you are ready to implement on real hardware, the next step is constraints. Without a UCF or SDC file, the tool guesses where your pins go. That guess is almost never what you want. Define your clock pin, your reset pin, and any other I/O. I learned this the hard way by assuming the default pin assignments matched the board documentation, which they never do. Resources for this topic are scattered. Textbooks like Digital Design and Computer Architecture by Harris and Harris cover the logic design side well but are light on VHDL specifics. For the language itself, looking at existing open-source projects on GitHub is better than any single tutorial. The Nand2Tetris course covers the design side but uses a different hardware description style. It is useful for concepts but you will need to translate the mental model to actual VHDL syntax. The main limitation of this approach is that VHDL has a steep learning curve for people coming from software. The parallelism is not intuitive. Everything happens at once, and the keywords determine whether a block synthesizes into registers or combinational logic. The language is verbose by design, and that verbosity is what catches you out when you miss a semicolon or a begin. There is no shortcut around reading the synthesis report line by line. It is tedious but necessary.
If you find VHDL too cumbersome for simple projects, Verilog is lighter and faster to write. But for anything that needs to be robust and portable across vendors, VHDL remains the better choice. That is the practical tradeoff. You pay more in upfront effort for less pain later when the project grows beyond a single FPGA family. Start small. Simulate before you synthesize. Read the logs. Fix the latches. Move on.
