Tool Setup for VHDL

1. Intuition — every toolchain does the same four jobs

Tools differ in name, price, and polish, but the flow is universal. To go from VHDL text to an inspectable result, a toolchain must:

1. Analyse (compile) your source files into a library,
2. Elaborate a chosen top unit into a complete design,
3. Simulate that design so you can watch its signals, and — for real silicon —
4. Synthesize the synthesizable part into gates.

Learn these four as steps, not as buttons in one vendor's GUI, and every tool becomes familiar: you are always just doing these, in this order.

2. The flow, step by step

• Analyse — each file is checked and stored in a library (work by default), in dependency order (packages before users, entity before architecture). This is where syntax and type errors surface.
• Elaborate — pick the top unit (often the testbench) and the tool binds entities to architectures and builds the design tree. Binding and generic errors surface here.
• Simulate — run the elaborated design over time and dump a waveform file to inspect in a viewer. This is how you check behaviour — exactly the reg_en waveform you saw in the previous lesson.
• Synthesize (optional, for hardware) — feed the synthesizable RTL (not the testbench) to an FPGA or ASIC tool to produce a gate netlist, then place-and-route for a device.

3. A minimal command flow

Conceptually, the commands are always "analyse each file, elaborate the top, run it." Here is that flow with one open-source toolchain (GHDL) as a concrete example — the shape is what matters, not the specific tool:

# 1. analyse sources in dependency order (design before testbench)
ghdl -a reg_en.vhd
ghdl -a tb_reg_en.vhd
 
# 2. elaborate the top unit (here, the testbench)
ghdl -e tb_reg_en
 
# 3. run and dump a waveform to inspect in a viewer
ghdl -r tb_reg_en --wave=reg_en.ghw

A commercial simulator spells the same three steps differently (a compile command, an elaborate/optimise step, then a run script), and an FPGA suite wraps them behind a project GUI — but it is still analyse, elaborate, run. Open the resulting waveform in a viewer (GTKWave for the open-source flow, or the simulator's built-in viewer) to see your signals.

4. Project files through the flow

A design is more than one file, so it helps to picture the files moving through the steps:

5. Organising a beginner project

A clean layout keeps the build order obvious and the design separate from its tests:

my_project/
  rtl/
    reg_en.vhd          # one entity per file; file name = entity name
  tb/
    tb_reg_en.vhd       # testbenches kept apart from synthesizable RTL
  sim/
    run.sh              # the analyse → elaborate → run commands
    reg_en.ghw          # generated waveform (not source)

Three habits that pay off immediately:

• One entity per file, named after the entity (reg_en → reg_en.vhd). Tools and teammates find units by filename.
• Keep RTL and testbenches in separate folders. Only rtl/ goes to synthesis; tb/ is simulation-only. The separation prevents non-synthesizable code from leaking into a build.
• Put the build in a script. A short run.sh (or Makefile) that lists files in dependency order is your single source of truth for compile order — far better than remembering it by hand.

6. The tool landscape, briefly

You do not need to pick the "right" tool to learn — any of these completes the flow:

• Simulators turn RTL + testbench into waveforms (open-source and commercial options exist; all perform analyse/elaborate/run).
• Waveform viewers display the dumped signals so you can verify behaviour.
• Synthesis / FPGA / ASIC tools map synthesizable RTL to gates and onto a device.

This lesson intentionally avoids install steps and version-specific instructions: those change constantly and differ per tool, while the flow above does not. Pick any simulator that runs on your machine and drive it with the four steps.

7. Common mistakes & what to watch for

• Analysing files in the wrong order. "Unit not found" almost always means a dependency was not compiled first — let your script enforce package → entity → architecture → top order.
• Mixing testbench code into the RTL folder. Non-synthesizable constructs then sneak into synthesis; keep tb/ separate.
• Editing a file but not re-analysing it (or its dependents). The library goes stale and you debug a version you already changed.
• Skipping the waveform. Simulation without looking at the signals is not verification — open the viewer and check the behaviour you expect.

8. Summary & next step

Every VHDL toolchain does the same four jobs — analyse, elaborate, simulate, and optionally synthesize — and learning them as steps makes any tool approachable. A tidy project (one entity per file, RTL and testbench separated, a script that fixes compile order) keeps the flow smooth from day one.

That completes the Foundations of VHDL: you can read and write an entity and architecture, you understand ports, types, libraries, the build flow, simulation versus synthesis, and you have a complete first design and a way to run it. From here the track moves from describing a single block to the language's real depth — the type system and the modeling styles (combinational, sequential, and structural RTL) that turn these foundations into production hardware.