<cr1901_modern>
_florent_: I'm reading the message you sent to the mailing list recently. Is a simulation entering an infinite loop always a bug in the simulator?
tija has quit [Quit: Connection closed for inactivity]
<larsc>
if you have a combinatorial loop there is not much the simulator can do
<cr1901_modern>
Yea, that's true. I'm asking b/c I have a simulation stuck in an infinite loop, but am having trouble diagnosing it.
<larsc>
well, you probably have a combinatorial loop ;)
<cr1901_modern>
FWIW, changing one self.comb to self.sync fixes the loop, so you're most likely right. I would just like to know the "why" in addition to the "what"
<larsc>
I think with iverilog you can do ctrl+c and then enter the finish command in the interactive mode
<larsc>
that allows you to abort the simulation
<cr1901_modern>
Python3 captures ctrl+c :( (using Migen simulation b/c idk how to fake the VPI without Migen running)
bentley` has joined #m-labs
<mithro>
so - It looks like there is some major migen/misoc restructuring going on?
sb0 has joined #m-labs
cr1901_modern has quit [Ping timeout: 260 seconds]
sb0_ has joined #m-labs
sb0__ has joined #m-labs
sb0 has quit [Ping timeout: 264 seconds]
sb0_ has quit [Ping timeout: 246 seconds]
mumptai has joined #m-labs
cr1901_modern has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 264 seconds]
sb0_ has joined #m-labs
sb0__ has quit [Ping timeout: 250 seconds]
sb0__ has joined #m-labs
sb0_ has quit [Ping timeout: 260 seconds]
<_florent_>
cr1901_modern: you can create infinite loops deliberately, but here the issue is when simulating large designs, it's difficult to avoid that with the way migen generates verilog
<_florent_>
I have a workaround in my migen fork (from david c) but that's not the right way to do it
<_florent_>
sb0 is going to add python simulation of fhdl and only use iverilog when there is a verilog or vhdl instance that needs to be simulated with a simulator
sb0 has joined #m-labs
sb0__ has quit [Ping timeout: 268 seconds]
sb0_ has joined #m-labs
sb0 has quit [Ping timeout: 250 seconds]
sb0__ has joined #m-labs
sb0_ has quit [Ping timeout: 264 seconds]
cr1901_modern1 is now known as cr1901_modern
sb0__ has quit [Ping timeout: 246 seconds]
<cr1901_modern>
Will the VPI code be kept for other simulators?
<_florent_>
vpi only exists for icarus no?
<cr1901_modern>
I thought all simulators were supposed to support VPI
<_florent_>
yes, but for now icarus is the only simulator supported by migen
<cr1901_modern>
ahhh, see I thought verilator was also supported
<_florent_>
verilator is supported, but it's not using vpi, it's simulating the whole SoC at the top level
<cr1901_modern>
Hmmm... maybe I should see if I can crash verilator with my design. Still have infinite loop that I can't find :/
<_florent_>
that's more a discussion, but we will probably remove the topics I created some month ago and add the features rjo was suggesting
<_florent_>
the idea is to stabilize migen API, move some things from migen to misoc, cleanup/reorganize misoc and add more tests to ease regression testing and eventually add travis-ci to misoc
nicksydney has quit [Remote host closed the connection]
<cr1901_modern>
_florent_: I just discovered the display_run parameter
<cr1901_modern>
It tells me which combinational statements are running and causing the loop
mumptai has quit [Quit: Verlassend]
sb0 has joined #m-labs
<GitHub131>
[misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vZtOV