-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calling Simulation::add_testbench
multiple times makes the simulations interfere with each other
#30
Comments
Simulation::add_testbench
makes the simulations interfere with each otherSimulation::add_testbench
multiple times makes the simulations interfere with each other
I don't think this is a problem of multiple test-benches, I think the problem is that the two testbenches are "fighting" over the inputs to your circuit. From what I can see, during the first 10 microseconds, both testbenches are driving the same inputs of the circuit to different values. In a physical circuit this would cause bad things to happen. I don't think I can detect this condition, since it is hard to enforce the single-writer principle in the testbenches. Does that make sense? In RustHDL, test-benches execute on the same circuit simultaneously. If you want to have 2 separate test cases, you need to run 2 separate simulations. |
Alternately, if you want to run multiple test benches sequentially in the same simulation, you need to make the second one wait until the first one is done (by adding a 10 microsecond wait at the beginning, for example), or just putting both test cases into a single testbench and executing them sequentially. |
Not really. I don't see the point in allowing multiple parallel test-benches if they're going to "fight" over the same circuit. Couldn't they each clone the circuit? Or, well, since blocks don't necessarily implement clone, what's the point of having multiple test benches in the same sim at all? Why not allow a single bench per test? Even if this is the intended behavior, it feels like it kind of goes against the Rust ethos to have this hidden footgun that fires without the program even warning you about it.
That's what I ended up doing. |
Minimal example:
(note the absence of clocks; I don't know if it's a factor)
When the tests are added in the order above, the simulation hangs instead of succeeding. If they're added in the opposite order, (TEST_B then TEST_A), the simulation succeeds.
If TEST_A is changed to fail, there are two scenarios:
Basically the simulation only "remembers" the last test.
The text was updated successfully, but these errors were encountered: