lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs :: Mixxeo preorder lists.milkymist.org/pipermail/devel-milkymist.org/2013-May/003344.html
<davidc__> BTW - anyone looked at TORC? (http://torc-isi.sourceforge.net/subversion.php) azonenberg; might be of interest to you.
mumptai has joined #milkymist
sh4rm4 has quit [Ping timeout: 240 seconds]
sh4rm4 has joined #milkymist
Scopeuk-AFK is now known as Scopeuk
sh4rm4 has quit [*.net *.split]
sh4rm4 has joined #milkymist
jaeckel_ is now known as jaeckel
lekernel has joined #milkymist
<davidc__> lekernel: around? Any thoughts on that patch I just sent for group_by_target [I'm about to head to bed; just wanted to see if that was the sane approach]
<davidc__> w/win 12
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
mumptai has quit [Ping timeout: 246 seconds]
<lekernel> davidc__, looks good
<lekernel> i.e. it really should return ({A, B}, [statement1, statement2, statement3]) in that case
<lekernel> do you really need resort_statements?
<lekernel> davidc__, how about this? http://pastebin.com/9dwg1DVi
<lekernel> + remove enumerate()
bhamilton has joined #milkymist
bhamilton has left #milkymist [#milkymist]
<lekernel> davidc__, I checked that resort_statements does nothing after this modification, using the whole milkymist-ng codebase.
<GitHub164> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/ESj9aA
<GitHub164> migen/master 939f01c Sebastien Bourdeauducq: fhdl/tools/group_by_target: remove resort_statements
<GitHub164> migen/master 16ebe41 David Carne: fhdl/tools: BUGFIX: fix group_by_target grouping...
<ysionneau> good to see a lot of contributions those days :)
<lekernel> interestingly enough, this patch seems to send the ISE *router* into an infinite loop
<lekernel> ah no, just super slow and fails timing
<lekernel> and the design and several simulations still work so I guess I can just blame it on ISE's shittiness
<ysionneau> change the random seed and jump on one foot around the computer
lekernel has quit [Ping timeout: 264 seconds]
lekernel has joined #milkymist
playthatbeat has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
playthatbeat has joined #milkymist
<GitHub23> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/mokXlg
<GitHub23> migen/master 9190568 David Carne: genlib/fifo/AsyncFIFO: fix data corruption bug
<lekernel> yay, 1080p output works without a glitch on LASMI
<GitHub110> misp/master a26b627 Sebastien Bourdeauducq: sync with milkymist-ng
<GitHub110> [misp] sbourdeauducq pushed 1 new commit to master: http://git.io/cQ6PXw
<GitHub164> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/zr8mww
<GitHub164> milkymist-ng/master 525c329 Sebastien Bourdeauducq: software/memtest: fix bandwidth computation
<ysionneau> \o/
<ysionneau> congrats!
<GitHub9> milkymist-ng/master fb06d80 Florent Kermarrec: s6ddrphy: revert CAS LATENCY 3 (configurable CAS Latency was buggy)
<GitHub9> [milkymist-ng] sbourdeauducq pushed 3 new commits to master: http://git.io/vbszTA
<GitHub9> milkymist-ng/master ea65aaa Sebastien Bourdeauducq: s6ddrphy: cleanup
<GitHub9> milkymist-ng/master da2b7aa Sebastien Bourdeauducq: cif: fix indentation
antgreen has quit [Ping timeout: 256 seconds]
<davidc__> lekernel: IIRC that simpler sorting code doesn't work in all cases
<azonenberg> lekernel: 1080p video using what interface?
<azonenberg> that hacked-up QDR setup on spartan6?
<davidc__> lekernel: for example ({A}, stmt1), ({B}, stmt2), ({A}, stmt3), ({B}, stmt4), ({A, B}, stmt5)
<lekernel> azonenberg, VGA
<azonenberg> lekernel: oh, lol
<azonenberg> So parallel 24-bit data to a DAC?
<davidc__> lekernel: without the explicit sort that would result in stmt1, stmt3, stmt2, stmt4, stmt5
<lekernel> yes
<davidc__> lekernel: I have a bit different coding style [which is perhaps invalid in migen] so I think I trigger it :)
<lekernel> do you have examples of that coding style?
<lekernel> curious :)
<davidc__> lekernel: sure self.sync += foo.eq(foo_next); self.comb += foo_next.eq(foo); (...deep in fsm act statement....) foo_next.eq(bar)
<lekernel> that sounds ok
<davidc__> lekernel: if you don't include the explicit reorder and the statements are in the seq described above; that fails :)
<davidc__> Let me just make sure though with my failing code.
<lekernel> ah yes
<davidc__> Ironically enough now of course I can't replicate my testcases failing without the resort :)
<davidc__> But I think the resort is correct; no?
<lekernel> it is correct, it just looks a bit heavy-handed
<GitHub161> [migen] sbourdeauducq pushed 2 new commits to master: http://git.io/OOVfnw
<GitHub161> migen/master 411e6ec Sebastien Bourdeauducq: fhdl/tools: do not export resort_statements
<GitHub161> migen/master d5d2e64 Sebastien Bourdeauducq: Revert "fhdl/tools/group_by_target: remove resort_statements"...
<davidc__> lekernel: yeah; I didn't see a nicer way :). If I think of one, you'll get a patch.
<davidc__> lekernel: Also, for the SyncFIFO; there's no bypass between ports [there is on the same port]
<davidc__> (er, on the S6, that is)
<lekernel> yes, but that should be OK - there is the synchronizer latency after the first write
<lekernel> which is > 2 cycles of the read clock, so the read port should always get clocked
<davidc__> lekernel: for the AsyncFIFO; yes - I meant for tweaks to the SyncFIFO so it can be mapped to BRAMs
<lekernel> ha
<lekernel> but iirc Xst adds some logic in that case
<lekernel> that compares the addresses and muxes the read data to a register containing the written data, using the fabric
<davidc__> lekernel: perhaps. I'll poke at that tonight to see if I can get a large syncfifo into a BRAM. If not; adding the logic manually is easy enough
<lekernel> yes. but Xst should even do that for you - which is preferable as it could be mapped to hard logic on architectures that might have it
<lekernel> so I'd say try that first, and look at the manual logic only if there are bugs or other issues
<davidc__> lekernel: btw - did XST/timing start working again after that patch? [I'd hate to think I broke ISE for you; I know how hard to placate it can be when it gets in one of its moods]
<lekernel> on the M1 the timing issues have moved to the DVI clocks and are only off by a fraction of a nanosecond - still better than what the expansion board can really do
<lekernel> there are no problems on the mixxeo
<lekernel> ha actually it's fine now. not sure what I changed though.
<lekernel> but several daily ISE breakages is just business as usual anyway ....
<davidc__> lekernel: heh; I did a 150mhz core clock design in an S3E... everything had to be LOCed by hand [down to the LUT, in some cases] to get it to consistently meet timing
antgreen has joined #milkymist
antgreen has quit [Ping timeout: 240 seconds]
Martoni has quit [Quit: ChatZilla 0.9.90.1 [Iceweasel 17.0.7/20130626001350]]
lekernel has quit [Quit: Leaving]
mumptai has joined #milkymist
antgreen has joined #milkymist
<ysionneau> urjtag git server is slow as hell
<ysionneau> "remote: counting objects" takes forever
<ysionneau> hum, urjtag does not compile on OSX
* ysionneau is not surprised
<ysionneau> hum, comment the line that does not compile, and it does
<ysionneau> weird though
<larsc> hopefully it will still work
<ysionneau> yep, it was something about readline
<ysionneau> cool I am able to send fjmem.bit to the Spartan 6 on the M1 via urjtag on OSX
antgreen has quit [Ping timeout: 248 seconds]
mumptai has quit [Ping timeout: 240 seconds]
sh4rm4 has quit [Ping timeout: 240 seconds]
sh4rm4 has joined #milkymist
ysionneau has quit [Ping timeout: 240 seconds]
ysionneau has joined #milkymist
antgreen has joined #milkymist