#milkymist IRC log for Thursday, 2013-11-28

davidc__Ok; I think I've found a workaround for the sim-hang issue. Its sorta ugly, but it works, and still allows cyclic deps04:19
davidc__I modded _printnode / _printcomb to print a comb block per target. This breaks the accidental-block-triggering loop; so iverilog actually works04:22
davidc__Downside is that the verilog becomes _much_ more verbose; since all of the If/Case statements are repeated04:24
davidc__ISE still seems to produce working bitstreams; and iverilog sim times are shorter; at the expense of verilog readability04:25
davidc__Right now it can't handle self.comb += Cat(x,y,z).eq(....); it requires LHS'es to be Signal's04:30
davidc__but I think a lowering pass can turn the Cat(x,y,z).eq() into x.eq(...[:]) statements04:33
rjodavidc__: what are the disadvantages of bundling stuff (mibuild, platforms, even misoc) with migen?05:21
davidc__rjo: well; misoc is very milkymist specific; most of the cores are for heavyweight busses05:31
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 APIs05:32
rjodavidc__: imho 9/10 of the misoc cores are parts of a generic soc!06:44
rjodavidc__: what would prevent stabilizing the migen api?06:45
rjodavidc__: everything except maybe the counteradc, and dvisampler is in fact generic.06:46
rjodavidc__: 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.06:50
davidc__rjo: I disagree with (b)06:57
davidc__rjo: I have several migen designs; none of which use misoc06:58
rjodavidc__: oh. with cores i meant to include the "cores" in migen/genlib, bus, bank as well07:01
rjodavidc__: 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.07:01
rjodavidc__: and especially you dont use the things in misoc, how would bundling them with misoc hurt? (apart from a few kB more data)07:06
davidc__bundling them with migen you mean?07:06
rjodavidc__: yes.07:07
rjodavidc__: all these m-things. the next name must be "m&m".07:07
Action: rjo wonders when "mi" became "m"07:08
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 :P07:08
rjodavidc__: 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.07:10
rjodavidc__: 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".07:11
davidc__rjo: git-submodule ?07:12
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 tree07:13
rjodavidc__: what a pain.07:14
rjodavidc__: 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.07:15
rjodavidc__: 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.07:17
davidc__rjo: exactly :)07:18
rjodavidc__: but are there any alternatives?07:18
davidc__rjo: well, there's the status quo, which is separate projects/groups keep their own cores in their own packages07:20
davidc__and you import as needed07:20
davidc__(and use tools like git-submodule to track the versions you're working against)07:21
rjodavidc__: philosophically, fifos, memories, fsms, bus components, coders, algorithmic cores like cordic all would be the same "non-basic" category as a uart, spiflash, cpu...07:21
davidc__rjo: I'd draw the line between fifos, memories, fsms | bus components, coders, cordic07:23
davidc__LHS is all basic digital HW uses, RHS is more specialized07:23
rjodavidc__: hmm. cdc? roundrobin? the higher level flow components? half of the actorlib?07:25
rjodavidc__: i agree that this distinction appears more natural than the current one.07:25
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 now07:26
davidc__anyhow, its really not my call anyhow - lekernel is the guy who writes all the code, hence his rules :)07:26
davidc__speaking of which, I have another few hundred lines to write tonight07:26
davidc__'later07:26
rjodavidc__: as long as the ugly/rare/specific cores don't hurt the more basic/frequently used ones i dont see the problem.07:27
rjodavidc__: cu.07:27
davidc__lekernel: I found what seems to be a minimally intrusive fix to the sim issue15:45
davidc__lekernel: specifically; I just create one always @(*) block per target (rather than group_by_targets)15:45
davidc__lekernel: and have modified printnode to support a filter argument that prunes what is printed15:46
lekernelhmm, I fear that it might make the verilog quite unreadable... and that it might break some synthesizer optimizations15:53
davidc__lekernel: yup; definitely comes at the expense of readability15:54
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 design15:56
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(...[:])15:57
lekernelI think readability is rather important, e.g. when debugging some code generation that went wrong15:58
lekernelhow large was your test design?15:59
davidc__lekernel: 3k LOC python roughly16:00
davidc__lekernel: I'll try it on misoc at some point; though I don't have HW to validate the bitstream on16:00
davidc__http://david.carne.ca/print1.patch if you feel like poking at it (completely uncleaned - still includes debug crud)16:04
Action: ysionneau just tested to run milkymist-legacy SoC with modified BIOS with MMU and ASID enabled, it works very well :)16:12
ysionneauthe BIOS runs perfectly well with a 1:1 virtual to physical memory mapping16:12
ysionneauall at ASID 016:12
ysionneauI 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 :)16:15
ysionneauaouch, with full milkymist legacy soc design : 2 constraints were not met16:45
ysionneau:-(16:45
ysionneauit complains about usb_clk and sys_clk16:47
ysionneauwtf, I did not change anything about usb part16:47
ysionneauhum I did not see any of what I added in the critical paths for sys_clk, it's still interrupt<->cache stuff16:52
ysionneauI tried the bitstream anyway, and it successfully loaded flickernoise GUI :)16:52
ysionneauISE timing report ...16:52
lekernelyeah, adding stuff sometimes breaks paths elsewhere in the design. at times, even in a different clock domain :)16:54
lekernelwell not only adding stuff - *removing* can have the same effect16:55
ysionneaulekernel: according to the timing report sys_clk should not work properly, but it still runs fine ^^16:59
ysionneauweird16:59
lekernelyes; the opposite situation (says it works, but does not) also happens at times17:00
lekernelyou can sometimes find those cases by cooling the FPGA to negative temperatures and see if it improves things17:00
lekernelit's a pain17:01
davidc__ysionneau: you forgot to sacrifice the goat before starting PAR17:02
ysionneauwa ....17:02
lekernelI wonder if the new vivado tools improved there17:02
ysionneauhum didn't try17:02
ysionneaustill running ISE 14.2 here17:03
lekernelvivado only works with 7 series fpgas anyway17:03
davidc__ysionneau: what I mean is; ISE timing closure + behaviour falls into the same category as black magic :)17:04
larscthe darkest of black magic ;)17:07
larscfun fact I learned the other day, vivado does not support localparam17:08
ysionneauahah17:14
ysionneaucool for lm32 which has plenty of them17:14
ysionneaufuse does not support the way our lm32 submodule declares log2 out of any module btw17:15
ysionneaucannot simulate with fuse anymore17:15
larscthere is a $log2 in the standard now17:16
larscmaybe fuse supports that17:17
larsc$ilog217:17
lekernelanother small reason for rewriting lm32 with migen ;)17:18
lekerneliirc it compiled with vivado, though17:19
GitHub122[qemu] mwalle pushed 1 new commit to master: https://github.com/mwalle/qemu/commit/89ed88b1cc02f954610748725409c54508e702a518:24
GitHub122qemu/master 89ed88b Michael Walle: linux-user18:24
GitHub94[qemu] mwalle force-pushed for-upstream from d600492 to f9a8c2e: https://github.com/mwalle/qemu/commits/for-upstream18:24
GitHub94qemu/for-upstream c74f41b Paolo Bonzini: x86: fix migration from pre-version 12...18:24
GitHub94qemu/for-upstream 2560f19 Paolo Bonzini: x86: cpuid: reconstruct leaf 0Dh data...18:24
GitHub94qemu/for-upstream c7679d4 Alex Williamson: vfio-pci: Add support for MSI affinity...18:24
ysionneauah nice, lm32 linux-user :)18:36
ysionneaupretty cool18:36
ysionneaulm32-rtems4.11-objcopy -O verilog test_add.elf test_add.vh19:25
ysionneau*** stack smashing detected ***: lm32-rtems4.11-objcopy terminated19:25
ysionneaunice one :)19:25
ysionneaurha, impossible to use the verilog backend :(19:27
larscverilog backend of what?19:34
ysionneauof objcopy19:36
ysionneauI'm going to do -O binary and then postprocess19:36
larscobjcopy has a verilog backend?19:40
larscah19:41
larscyou want to output a rom19:41
ysionneauyes20:02
ysionneaufor those unitests https://github.com/m-labs/lm32/blob/master/test/unittests/Makefile20:02
ysionneauhexdump test_mmu_nop1.vh | head -n2 | awk 'BEGIN { FS=" " } ; { for (i = 2 ; i < NF ; i++) { printf "%s ",$i } ;  print "" }' | sed -e 's/\([0-9a-fA-F]\{2\}\)\([0-9a-fA-F]\{2\}\)/\1 \2/g'20:02
ysionneauit does the trick20:03
davidc__srec_cat probably does too :P20:20
larsclekernel: https://github.com/m-labs/migen/blob/eb1bd718082d9934c5d7067a275a09b1cdf68284/migen/genlib/fifo.py#L11120:38
larscwhy -2 as well, wont that cause overruns?20:39
lekernelhmm, I haven't had problems with those FIFOs20:41
lekernelhmm20:42
larsce.g. consider http://pastebin.com/QrWngu9220:42
larscif I understand that paper correctly you should only check the most upper bit20:42
lekernelhttp://www.csee.umbc.edu/~tinoosh/cmpe415/tutorials/FIFO.pdf20:45
lekernelp.1120:45
larscbut those are gray codes20:46
larscah ok20:47
larscno, what is q?20:47
larscin gray code or in non-gray?20:47
lekernelgray20:48
lekernelall FIFO pointer comparisons must be done in gray code20:49
larscok20:49
larscmissed that20:49
lekernel"9.0 DesignWare FIFOs" is quite funny =]20:53
lekernelsounds familiar20:54
larscah, ok compare is done in gray, but indexing is done in binary20:58
lekernelyes, because you need to wrap around when removing the MSB21:01
larscyea, but the paper also has a section on how to convert a n gray code to a n-1 gray code21:03
lekernelyes, but I'm not using that, since the counter already counts in binary internally21:10
larscyep21:10
larscthe interesting part is that you don't have to do any backconversion from gray to binary21:13
larscsince that tends to be a bit more expensive21:13
larscI think21:13
ysionneauwho wanted a small Spartan 6 LX9 fpga dev board? http://www.lextronic.fr/P29761-platine-de-developpement-fpga-mojo-v3.html21:58
wpwrakwhitequark was looking for one. but i think he's getting the one lekernel uses22:39
lekernelno sdram? hmm22:40
wpwrakthe mojo looks nice. finally someone had the courage not to add RAM :) alas, it costs just as much as those with RAM.22:41
wpwraklekernel: ideal for fpgatools development :)22:42
wpwrakhttps://www.sparkfun.com/products/1195322:46
wpwrakSkills: Electrical Prototyping - Noob :)22:46
wpwrakand it makes sense. only a noob wouldn't notice that two pages are missing in their schematics :)22:48
--- Fri Nov 29 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!