Learn

0/8
0/6
0/6
0/6

Practice

One Lamp, One Driver

The BUSY lamp of a lab machine must light whenever the heater or the pump is running. The template you get contains the classic version of this bug. The heater code drove the internal busy line first. The pump code was added later as a second driver of the same signal. Run it as-is and the lamp reads 'X' whenever exactly one subsystem is on, and looks perfectly healthy whenever the two agree. That's the trap of a resolved type: the fight only shows where the drivers disagree.

Don't debug the waveform. Make the compiler find the bug: switch the internal busy line to the strict kind from the lesson and rebuild.

  • VHDL: elaboration now stops with several sources for unresolved signal and names the line.
  • SystemVerilog: the buggy busy was a wire, the resolved kind, so two drivers were legal; with the strict kind, compilation now stops with Unresolved net/uwire busy cannot have multiple drivers.

With the compiler pointing at the guilty wire, merge the two drivers into one and run again.

Interface

PortDirectionTypeDescription
heater_onin1 bitHeater is running
pump_onin1 bitPump is running
lampout1 bitBUSY lamp: high while anything runs

Declarations: VHDL, all ports std_logic; SystemVerilog, all ports logic.

Behavior

  • lamp is '1' when heater_on is '1', when pump_on is '1', and when both are
  • lamp is '0' only when both inputs are '0'
  • All four input combinations are checked; no 'X' may appear anywhere

Constraints

SINGLE DRIVER

the busy line stays a named internal signal with exactly one driver, and lamp keeps reading it.

  • The final declaration uses the strict kind: std_ulogic (VHDL) / logic (SystemVerilog). The testbench can only check values, so the strict declaration is your own guard, and the compile stop on the unfixed code is how you know it's working
  • Expect the first run to fail on the mixed rows; that 'X' in the waveform is the bug you're hunting
Loading editor...

Click Run to execute your code. Output will appear here.