<wpwrak>
hmm, do we expect ("mass"-production) m1r4 to ship with the current gateware base or already something migen-based ? considering the typical production schedule, m1r4 may start shipping in something like 3 months.
<wolfspraul>
don't even ask that
<wolfspraul>
all I want is accelerate, everywhere
<wolfspraul>
we are doing too many things at once
<wolfspraul>
worst case I make more rc3 :-)
<wolfspraul>
I think migen is months out
<wpwrak>
it has practical implications. e.g., whether we should implement support for new hardware features for the plain verilog code base or for migen
<wolfspraul>
I hope we can finish the kicad switch, boom, flickernoise improvements, better software update schedule and announcements
* kristianpaul
likes human wrote SoC for now
<wpwrak>
yeah, so far, i find verilog reasonably friendly. it has some unnecessary quirks, though. they could have tried to stay closer to C :)
<wpwrak>
what i haven't figured out yet is how to efficiently move data paths around. things that touch many interfaces. the "just make the same change in 10 different files" approach isn't too nice. and that's of course, something where migen should shine.
voidcoder has joined #milkymist
<larsc>
in my opinion the abstraction level in verilog is to low
<larsc>
and migen doesn't help much either
Thorn__ has joined #milkymist
Thorn__ has joined #milkymist
<wpwrak>
larsc: you mean for the modeling of what goes on in the function blocks or for piecing things together ?
<wolfspraul>
larsc: do you know myhdl? do you think that's any better?
<wolfspraul>
vhdl? other tools?
<wolfspraul>
which abstraction could work better in your opinion?
<wpwrak>
i usually don't mind a low level of abstraction, as long as the language is flexible and friendly. C is a good example. doesn't have a lot of built-in things, but you can grow your own language out of it.
<larsc>
for example i really don't want to be bother with inserting buffers at the right positions.
<larsc>
i want to write down the supposed functionallity and give the block a overall timing constraint
<larsc>
and then let the sythesizther do its magic
<larsc>
also this allows for much better code reusability since I can actually write down the same code no matter if I want a combinatorical, sequential, pipelined or any mix of them design
<wolfspraul>
how about those other tools? anything you have in mind?
<wolfspraul>
need to broaden my horizon :-)
<larsc>
i've nothing found yet that does this
elldekaa has joined #milkymist
antgreen` has joined #milkymist
mumptai has joined #milkymist
voidcoder has joined #milkymist
<mwalle>
wpwrak: you're there?
antgreen has joined #milkymist
<mwalle>
wpwrak: could you please have a look at my patches, if they introduce any regressions? :)
<sb0>
I didn't bring a JTAG adapter and my LV3 is with Spencer atm so... can't test your patches until I'm back (May 13...)
<mwalle>
sb0: np, maybe i can convince wpwrak ;)
<sb0>
I'll ask Spencer too :)
<wpwrak>
mwalle: i'll have a look at it tomorrow. social obligations tonight. and i'll also have to install xst again. that file system problem a few weeks ago ate it too :-(
<mwalle>
btw what do you think about an auto-nak on in tokens? i'm too slow to respond to an in token in a timely manner. and since we don't have interrupts