08:40 <davidc__> lekernel: have you run into migen generated code that hangs iverilog [seems to be something about large sensitivity lists + non-blocking assignments in combinatorial code]

08:51 <lekernel> yes, https://ssl.serverraum.org/lists-archive/devel/2012-November/003172.html

08:52 <lekernel> other simulators have different behaviours ...

08:53 <lekernel> and yeah, verilog/vhdl are that bad

09:37 <cde> lekernel: what do you think about the free modelsim provided with altera? will it work with migen code?

09:37 <lekernel> iirc modelsim has the same problem

09:38 <lekernel> I also think it should not be too hard to fix in iverilog

09:38 <cde> thanks. what about vhdl?

09:39 <lekernel> bah, it can happen in either language, depending how the simulator implements this stupid event stuff

09:39 <cde> yes

09:39 <lekernel> I haven't tried to reproduce it in vhdl

09:40 <lekernel> but I can imagine it's the same pain in the ass

09:42 <lekernel> davidc__, if you use the display_run option for verilog conversion I guess you will see that iverilog keeps running a loop of combinatorial always blocks, even though the signal values do not change anymore

09:56 <lekernel> davidc__, if you use the display_run option for verilog conversion I guess you will see that iverilog keeps running a loop of combinatorial always blocks, even though the signal values do not change anymore

15:46 <davidc__> lekernel: Ok; I'll check that out to try and narrow it down. I made a few minimal testcases; and it should be settling just fine

15:46 <davidc__> [seems to be an issue where it should settle but doesn't]

15:49 <lekernel> the code from my email triggers the problem

15:49 <davidc__> so maybe I'll investigate fixing iverilog

15:49 <lekernel> even though it settles

15:57 <davidc__> lekernel: the other option could be to change to blocking assignments in combinatorial blocks; and split always blocks (magically; need to think more about the splitting)

15:57 <davidc__> lekernel: That option might actually be preferable - some simulators can theoretically go a lot faster with that coding style

16:00 <GitHub61> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/dr3paQ

16:00 <GitHub61> migen/master fcd48da Sebastien Bourdeauducq: examples/two_dividers: demonstrate InsertCE and InsertReset decorators

16:00 <GitHub61> migen/master b367932 Sebastien Bourdeauducq: fhdl: introduce module decorators

16:00 <GitHub2> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/Xrgssw

16:00 <GitHub2> milkymist-ng/master 8e04de5 Sebastien Bourdeauducq: memtest/LFSR: use module decorators

16:01 <lekernel> davidc__, iirc there were issues with blocking assignments, even in comb blocks

16:02 <davidc__> lekernel: blocking assignments wont result in the same code execution (can't retrigger same always block sensitivity list IIRC), so we'd need to split into multiple always blocks

16:02 <lekernel> yes, I remember a similar mess when i tried that

16:03 <lekernel> another option is to ditch verilog entirely for simulation, but then you can't simulate legacy verilog modules anymore

16:04 <lekernel> direct EDIF output would also be a desirable feature ...

16:05 <lekernel> the only real problems with existing verilog code are LM32 and simulation models such as xilinx unisim, micron models, etc.

16:05 <davidc__> lekernel: yeah :S. Anyhow; always-block-splitting looks to be possible for non-cyclic code [since combinatorial blocks should be a DAG]

16:05 <lekernel> LM32 could be done relatively easily by rewritting in FHDL

16:05 <davidc__> lekernel: eh; I run into a similar problem with my project. I have a bunch of verilog from earlier versions that I'd really rather not rewrite

16:06 <lekernel> perhaps with some semi-automated tool

16:06 <lekernel> unisim, micron models etc. are more of a problem since you don't want to track the bugs you may have introduced during the rewriting

16:07 <davidc__> Anyhow; I'll look at always-block-splitting, moving to blocking ops and see if its possible. Having the datastructures you'd need for that wouldn't be terrible anyhow; you could use them for things like direct LLVM IR emission; for really fast simulators

16:07 <lekernel> turning comb logic into clean DAGs is also a nice feature, since it's one step towards EDIF output :=

16:07 <lekernel> :)

16:10 <lekernel> it would potentially speed up simulations too. I found that iverilog runs the comb blocks way too many times with the current generated code.

16:12 <davidc__> lekernel: yeah. People recommend only-blocking-assignments-in-combinatorial-blocks for that reason; but that requires reordering; or always-block splitting

16:14 <lekernel> verilog is such a waste of time :) I wonder why people focus so much on simulation-only stuff like systemc instead of addressing those basic problems...

18:37 <GitHub0> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/rGMuWA

18:37 <GitHub0> migen/master b7ed19c Sebastien Bourdeauducq: fhdl: do not export Fragment

18:37 <GitHub0> migen/master b96eb33 Sebastien Bourdeauducq: fhdl: compact Instance syntax

20:14 <ysionneau> hum, mailing list max size for email is 40 kB, sorry about that

22:39 <GitHub80> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/_sCNWA

22:39 <GitHub80> migen/master b8ff2f2 Robert Jordens: genlib/roundrobin.py: fix n==1 case