Closed Necromaticon closed 4 months ago
Figured it out and it turned out to be a pretty simple mistake: "Variables propagate one step on each update!"
This means that in that first assignment uut.in1.next = 1
, the value of 1 is set as the next value for in1. So when calling update the value gets pushed into in1, but doesn't propagate through the OR gate yet. That would happen on a second update()
call!
Hi there!
So I've been playing around with this tool, reading the API doc, tutorial, and unit test examples, and I couldn't find anything about how one is supposed to drive inputs.
Picture this: You design a small module which you want to drive manually, no simulation macro, no clock cycles.
Driving this with something like:
The output in this case would be false, despite expecting true. Changing the two input signals to outputs would fix this, but would be an inelegant solution as soon as generating something into its Verilog equivalent will occur.
From RustHDL Signals I've gathered that inputs can not be driven, but I noticed that they can be accessed in the way mentioned above if wrapped inside a simulation.
Is there a way to set input values like that without having to simulate the modules completely?