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 signaland names the line. - SystemVerilog: the buggy
busywas awire, the resolved kind, so two drivers were legal; with the strict kind, compilation now stops withUnresolved 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
| Port | Direction | Type | Description |
|---|---|---|---|
heater_on | in | 1 bit | Heater is running |
pump_on | in | 1 bit | Pump is running |
lamp | out | 1 bit | BUSY lamp: high while anything runs |
Declarations: VHDL, all ports std_logic; SystemVerilog, all ports logic.
Behavior
lampis '1' whenheater_onis '1', whenpump_onis '1', and when both arelampis '0' only when both inputs are '0'- All four input combinations are checked; no
'X'may appear anywhere
Constraints
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
Click Run to execute your code. Output will appear here.