01:40 <barmstrong> hmm, i wonder how hard it would be to add 'after' support to migen

01:40 <davidc__> barmstrong: for the FSM?

01:41 <barmstrong> well, i'm thinking if i wanted to add verilog delays for simulation

01:43 <barmstrong> foo.eq(bar, after=2) -> foo <= bar after 2

01:43 <barmstrong> or something like that

01:44 <barmstrong> i guess in verilog that's #2 or something. my verilog is super rusty :)

01:50 <davidc__> shouldn't be too hard... but given that iverilog hangs on most migen output anyhow :P

01:51 <barmstrong> wait, what?

01:51 <barmstrong> i've been using iverilog with my design without too much issue so far

01:51 <barmstrong> is there something specifically i should look out for?

01:53 <davidc__> iverilog doesn't seem to settle properly

01:53 <davidc__> in some cases

01:53 <barmstrong> oh, hmm

01:53 <davidc__> mostly involving things where a var is set in one place, then If(var) in the other

02:03 <davidc__> barmstrong: it seems to work for small blocks, but hangs when you string a bunch into a pipeline; at least in our design it does

02:03 <davidc__> I have a custom migen patch (not really primetime ready) that reorders statements / does some splitting / etc such that everything can be combined into a big always block that just runs to completion

23:55 <sb0> barmstrong: what do you need those delays for, exactly?

23:57 <sb0> I'd rather not have them. they are not synthesizable, cause confusion (see all those xilinx source codes with <=#1), and add a fair amount of complexity that I believe is unwarranted

23:58 <sb0> complex designs like milkymist-ng are totally fine without them