-
Notifications
You must be signed in to change notification settings - Fork 175
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
Weird simulation behaviour with clock's and Instances #391
Comments
The behavior of |
I understand that, however I think that it should never be possible for anything that just reads the |
I agree of course. It's just a bug somewhere in the simulation code. I don't consider it a priority to fix since you can't really use |
Actually it seems like I was just bad at minimizing this example, the following snippet shows the same behaviour: from nmigen import *
from nmigen.back.pysim import Simulator
trigger_bug = False
class Bug(Elaboratable):
def elaborate(self, plat):
m = Module()
m.d.comb += ClockSignal().eq(0)
if trigger_bug:
a = Signal()
m.d.comb += a.eq(ClockSignal())
counter = Signal(8)
m.d.sync += counter.eq(counter + 1)
return m
simulator = Simulator(Bug())
simulator.add_clock(1e-9)
with simulator.write_vcd("test.vcd", "test.gtkw", traces=[]):
simulator.run_until(1e-8, run_passive=True) |
Thanks for clarification, I'll look into this ASAP. |
Ah so the problem here is that you're not allowed to override combinatorial signals in a simulation, but it's not currently checked. So this is a duplicate of #318. |
Ah of course, sorry for not connecting the dots. I encounter this problem mostly in a situation like this: a = Signal()
b = Signal()
m.d.comb += b.eq(a) Where |
No, unfortunately not. How is your code structured? |
Well this ties back to To make it easy to create AXI slave all over the design hierarchy, my platform gives access to a However the same problem also happens for example for clockdomains generated by a PLL. The PLL is obviously also a So the main problem is I would have to disconnect every Now that I have written all this out I have noticed that I already don't use So I guess sorry for the noise. (The code lives here https://github.com/apertus-open-source-cinema/nmigen-gateware if you actually want to see how its structured, but it probably breaks nmigen's intended usage in many ways :) |
Oh I see! Yeah, that's not currently handled well at all, but we already have two tracking issues for those: #113 and #308 (#308 isn't quite about Maybe you could comment there with your experience and desires? Then the design that eventually emerges would be guided by those.
Yep that's what I would suggest as a workaround.
Wouldn't that mean that nmigen's intended usage is wrong? Or at the very least, underdocumented or unfinished. Anyway, the main thing I see is that you're using your own CSR and SoC abstractions instead of nmigen-soc. |
I'm going to close this now in favor of the two issues I mentioned. |
Maybe, currently for example I don't see a easy way to to what SocPlatform in combination with this is doing without what feels like poking at nmigen internals a bit too much.
Yeah at the time it didn't feel like using |
Ah interesting, I'll remember to take a look at that. Right now I'm pretty busy with cxxrtl/cxxsim but SoC stuff is quite high on the list.
Nice, looking forward to hearing your thoughts on that. |
another useful way to handle this would be a simulator command, that disconnects a signal from all signals that drive it in the design to be able to drive it from the testbench. This was also a thing that I a few times when debugging a core and stubbing half of its functionality out. |
That would be pretty challenging to add on simulator level, especially if parity of pysim and cxxsim is desired. It might be a lot easier to add on code transformation level though. |
I have encountered a really weird bug in
pysim
when usingInstance
in combination withClockSignal
.The following example:
Produces this
vcd
output:Which is about what I would expect.
However if I set
trigger_bug
toTrue
I get the following output:Where the counter still works, but the
ClockSignal
is not driven.The behaviour doesn't change when swapping the
clk_source
Instance
for a constant0
assignment, it is just there to show a possible real world occurrence.The text was updated successfully, but these errors were encountered: