lekernel changed the topic of #milkymist to: Mixxeo, Migen, MiSoC & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
lekernel has quit [Quit: Leaving]
mrueg has quit [Ping timeout: 248 seconds]
mrueg has joined #milkymist
<davidc__>
Ok; I think I've found a workaround for the sim-hang issue. Its sorta ugly, but it works, and still allows cyclic deps
<davidc__>
I modded _printnode / _printcomb to print a comb block per target. This breaks the accidental-block-triggering loop; so iverilog actually works
<davidc__>
Downside is that the verilog becomes _much_ more verbose; since all of the If/Case statements are repeated
<davidc__>
ISE still seems to produce working bitstreams; and iverilog sim times are shorter; at the expense of verilog readability
<davidc__>
Right now it can't handle self.comb += Cat(x,y,z).eq(....); it requires LHS'es to be Signal's
<davidc__>
but I think a lowering pass can turn the Cat(x,y,z).eq() into x.eq(...[:]) statements
<rjo>
davidc__: what are the disadvantages of bundling stuff (mibuild, platforms, even misoc) with migen?
proppy has joined #milkymist
<davidc__>
rjo: well; misoc is very milkymist specific; most of the cores are for heavyweight busses
<davidc__>
rjo: Also, IMHO if migen is to be a widely used HDL metalang; it'll have to stablize at some point; which means not breaking APIs
<rjo>
davidc__: imho 9/10 of the misoc cores are parts of a generic soc!
<rjo>
davidc__: what would prevent stabilizing the migen api?
<rjo>
davidc__: everything except maybe the counteradc, and dvisampler is in fact generic.
<rjo>
davidc__: true, the "language" and the "cores" are on different levels of the hierarchy. but (a) that does not mean that the language can and will easily stabilize before the cores, (b) virtually everyone uses the cores and thus their volatile api is most relevant for them.
<davidc__>
rjo: I disagree with (b)
<davidc__>
rjo: I have several migen designs; none of which use misoc
<rjo>
davidc__: oh. with cores i meant to include the "cores" in migen/genlib, bus, bank as well
<rjo>
davidc__: your designs are most probably not a SoC. if you have a cpu, you will most probably want a lot of the things in misoc as well.
<rjo>
davidc__: and especially you dont use the things in misoc, how would bundling them with misoc hurt? (apart from a few kB more data)
<davidc__>
bundling them with migen you mean?
<rjo>
davidc__: yes.
<rjo>
davidc__: all these m-things. the next name must be "m&m".
* rjo
wonders when "mi" became "m"
<davidc__>
If they're just going to reside in a separate misoc dir; it doesn't really make a difference either way, except that changelogs get mixed together :P
<rjo>
davidc__: exactly. compare that with having to roll mi{gen,soc,build} commits in sync as one currently does if one wants to reconstruct some older point in time.
<rjo>
davidc__: as long as all three are relativly fast moving targets that need synchronization it would be much easier if they were in the same "package".
<davidc__>
rjo: git-submodule ?
<davidc__>
rjo: Also, long term, what goes into misoc? I imagine that the milkymist people won't want anything but their cores in there to avoid cluttering the tree
<rjo>
davidc__: what a pain.
<rjo>
davidc__: i don't know, to me the line between some of the more "core" like things (the bus components, a lot of things in genlib) in migen and the misoc things is hard to draw.
<rjo>
davidc__: the only thing that is frightening is that -- wherever such a "micores" library of cores ends up -- it would probably end up as disgusting as opencores.
<davidc__>
rjo: exactly :)
<rjo>
davidc__: but are there any alternatives?
<davidc__>
rjo: well, there's the status quo, which is separate projects/groups keep their own cores in their own packages
<davidc__>
and you import as needed
<davidc__>
(and use tools like git-submodule to track the versions you're working against)
<rjo>
davidc__: philosophically, fifos, memories, fsms, bus components, coders, algorithmic cores like cordic all would be the same "non-basic" category as a uart, spiflash, cpu...
<davidc__>
rjo: I'd draw the line between fifos, memories, fsms | bus components, coders, cordic
<davidc__>
LHS is all basic digital HW uses, RHS is more specialized
<rjo>
davidc__: hmm. cdc? roundrobin? the higher level flow components? half of the actorlib?
<rjo>
davidc__: i agree that this distinction appears more natural than the current one.
<davidc__>
rjo: I'm not saying that I think the current separation is perfect, I'm just saying that putting it all together is worse than what we have now
<davidc__>
anyhow, its really not my call anyhow - lekernel is the guy who writes all the code, hence his rules :)
<davidc__>
speaking of which, I have another few hundred lines to write tonight
<davidc__>
'later
<rjo>
davidc__: as long as the ugly/rare/specific cores don't hurt the more basic/frequently used ones i dont see the problem.
<rjo>
davidc__: cu.
lekernel has joined #milkymist
kyak has quit []
kyak has joined #milkymist
kyak has joined #milkymist
mumptai has joined #milkymist
xiangfu has joined #milkymist
sh4rm4 has quit [Ping timeout: 240 seconds]
xiangfu has quit [Ping timeout: 272 seconds]
xiangfu has joined #milkymist
mumptai has quit [Quit: Verlassend]
sh4rm4 has joined #milkymist
xiangfu has quit [Ping timeout: 241 seconds]
xiangfu has joined #milkymist
xiangfu has quit [Ping timeout: 248 seconds]
xiangfu has joined #milkymist
<davidc__>
lekernel: I found what seems to be a minimally intrusive fix to the sim issue
<davidc__>
lekernel: specifically; I just create one always @(*) block per target (rather than group_by_targets)
<davidc__>
lekernel: and have modified printnode to support a filter argument that prunes what is printed
<lekernel>
hmm, I fear that it might make the verilog quite unreadable... and that it might break some synthesizer optimizations
<davidc__>
lekernel: yup; definitely comes at the expense of readability
<davidc__>
lekernel: synth opts still seem to be OK - it does FSM recovery / etc. I saw no real change in FPGA utilization or timing on my design
<davidc__>
lekernel: I can post my diff; but it still needs some work (a lowering pass to convert Cat(x,y,z).eq(....) to x.eq(....[:]), y.eq(....[:]), z.eq(...[:])
<lekernel>
I think readability is rather important, e.g. when debugging some code generation that went wrong
<lekernel>
how large was your test design?
<davidc__>
lekernel: 3k LOC python roughly
<davidc__>
lekernel: I'll try it on misoc at some point; though I don't have HW to validate the bitstream on
* ysionneau
just tested to run milkymist-legacy SoC with modified BIOS with MMU and ASID enabled, it works very well :)
<ysionneau>
the BIOS runs perfectly well with a 1:1 virtual to physical memory mapping
<ysionneau>
all at ASID 0
<ysionneau>
I disabled a lot of cores on the M1 design to accelerate synthesis, let's enable all back, maybe it will even run flickernoise with MMU and ASID on :)
xiangfu has quit [Ping timeout: 272 seconds]
<ysionneau>
aouch, with full milkymist legacy soc design : 2 constraints were not met
<ysionneau>
:-(
<ysionneau>
it complains about usb_clk and sys_clk
<ysionneau>
wtf, I did not change anything about usb part
<ysionneau>
hum I did not see any of what I added in the critical paths for sys_clk, it's still interrupt<->cache stuff
<ysionneau>
I tried the bitstream anyway, and it successfully loaded flickernoise GUI :)
<ysionneau>
ISE timing report ...
<lekernel>
yeah, adding stuff sometimes breaks paths elsewhere in the design. at times, even in a different clock domain :)
<lekernel>
well not only adding stuff - *removing* can have the same effect
<ysionneau>
lekernel: according to the timing report sys_clk should not work properly, but it still runs fine ^^
<ysionneau>
weird
<lekernel>
yes; the opposite situation (says it works, but does not) also happens at times
<lekernel>
you can sometimes find those cases by cooling the FPGA to negative temperatures and see if it improves things
<lekernel>
it's a pain
<davidc__>
ysionneau: you forgot to sacrifice the goat before starting PAR
<ysionneau>
wa ....
<lekernel>
I wonder if the new vivado tools improved there
<ysionneau>
hum didn't try
<ysionneau>
still running ISE 14.2 here
<lekernel>
vivado only works with 7 series fpgas anyway
<davidc__>
ysionneau: what I mean is; ISE timing closure + behaviour falls into the same category as black magic :)
<larsc>
the darkest of black magic ;)
<larsc>
fun fact I learned the other day, vivado does not support localparam
kilae has joined #milkymist
<ysionneau>
ahah
<ysionneau>
cool for lm32 which has plenty of them
<ysionneau>
fuse does not support the way our lm32 submodule declares log2 out of any module btw
<ysionneau>
cannot simulate with fuse anymore
<larsc>
there is a $log2 in the standard now
<larsc>
maybe fuse supports that
<larsc>
$ilog2
<lekernel>
another small reason for rewriting lm32 with migen ;)