Topic for #milkymist is now Radical Tech Coalition :: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
<wpwrak> wolfspraul: (power from board) we have a perfectly good DC in connector already :)
<kristianpaul> indeed too
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
Technicus [Technicus!~Technicus@DSLPool-net212-23.wctc.net] has joined #milkymist
swivel [swivel!~swivel@shells.gnugeneration.com] has joined #milkymist
lekernel_ [lekernel_!~lekernel@g225040166.adsl.alicedsl.de] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
swivel [swivel!~swivel@shells.gnugeneration.com] has quit [#milkymist]
kyak [kyak!~kyak@unaffiliated/kyak] has joined #milkymist
mumptai [mumptai!~calle@brmn-4db70ebb.pool.mediaWays.net] has joined #milkymist
wolfspraul [wolfspraul!~wolfsprau@p5B0AB4D3.dip.t-dialin.net] has joined #milkymist
Martoni [Martoni!~chatzilla@ip-167-165.evhr.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@adm02.insa-rennes.fr] has joined #milkymist
<lekernel_> Fallenou: yes, you can use a dual ported RAM, they are for free compared to single-ported RAMs in a FPGA
<lekernel_> (but cost more in ASIC)
<lekernel_> larsc: time sharing as in "use a single actor to process certain parts of the data flow graph during certain cycles, and other parts during other cycles"
<lekernel_> like the "actors" in a CPU do :)
<larsc> ok
<larsc> thats probably going to be a bit more context finding actors which can be shared
<lekernel_> well, if you see one type of actor appearing 1000x in the DFG, and if you do not need or cannot have the performance that this parallelism brings
<larsc> btw. i've given the whole thing a bit more though and i think the basic property which can be used to describe any graph is the sequential delay
<lekernel_> then it makes sense to have only one of those actors, a little "register file" to store the tokens, and some microcode for scheduling
<larsc> pipeline delay is a bunch of elements with a sequential delay of one in row
<lekernel_> hm, if you have several pipelines in series, it makes a pipeline... not a sequential thing
<larsc> a buffer has a sequential delay of one
<larsc> a pipeline are buffers in row
<lekernel_> anyway, since generating the trigger signals is more complicated than I thought, I don't see much point in modeling the timing of parallel graphs
<lekernel_> it's the time-shared ones which are interesting
<lekernel_> and I'm pretty sure we can generate triggers and everything there, because that's basically what the PFPU system does :)
<wpwrak> paper is here: http://arxiv.org/abs/1201.2501v1
<wpwrak> that may be handy for improving our audio processing :)
<wpwrak> of course, i wouldn't have to implemenet it :)
<lekernel> nope... thanks, will bookmark it
<lekernel> of course, i wouldn't have to implemenet it :) <= ??
<wpwrak> the math doesn't look too easy
<wpwrak> but i didn't read it in detail. maybe the nasty bits are just proofs
azonenberg [azonenberg!~azonenber@cpe-67-246-33-188.nycap.res.rr.com] has joined #milkymist
xiangfu [xiangfu!~xiangfu@fidelio.qi-hardware.com] has joined #milkymist
Technicus [Technicus!~Technicus@DSLPool-net208-2.wctc.net] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
<xiangfu> wpwrak, still not finish the static ip address task. now is Chinese new year. the bigger holiday in China.
<xiangfu> wpwrak, I think I will try to finish that this week. ;)
<wpwrak> xiangfu: using the big holiday for some quiet work ? ;-)
<wpwrak> btw, happy new year ! ;-)
<xiangfu> thanks. happy new year.
<Fallenou> happy new year :) enjoy have fun!
<xiangfu> Fallenou, happy new year.
<Fallenou> thx
<xiangfu> wpwrak, BTW. the latest daily build make my mouse not working. it more like totally no power.
<xiangfu> wpwrak, when boot to bios. the mouse still have power. after boot to flickernoise the mouse totally no power at all.
<wpwrak> hmm, that's odd. i haven't touched that code for weeks.
<xiangfu> wpwrak, do you have any clue? if easy fix. I can take this task. :D
<wpwrak> also, in M1rc2/rc3, USB is always powered :)
<xiangfu> yes.
<xiangfu> from plug in power cable to bios. all fine.
<wpwrak> maybe try disconnecting and reconnecting a few times ? i have one mouse that also doesn't always comes up on the first try
<xiangfu> let me try now.
<xiangfu> reconnect 10 times. it have power only at the 1 second. then no power at all.
<wpwrak> hmm. seems that it fails enumeration and then shuts down on its own.
<wpwrak> do other USB devices work ?
<xiangfu> wpwrak, keyboard works fine
<wpwrak> and what version of the USB firmware did you have installed before ?
<wpwrak> i.e., from what date was the previous RTEMS ? very old ? or recent ?
<xiangfu> RTEMS 12-01.
<xiangfu> git://git.rtems.org/rtems.git master e493e2a83e8d76079cc84b50a098015492996a3c
<xiangfu> the last commit at 2011-12-01. :)
<wpwrak> and from what date was the build you used before ?
<wpwrak> i.e., the one where the mouse worked ?
proppy [proppy!u1692@gateway/web/irccloud.com/x-awnuyrmbdcmeiohp] has joined #milkymist
<wpwrak> the last changes to softusb that look like they could affect how the mouse works were from november 30
<xiangfu> I will try a early rtems. then let you know the result.
<xiangfu> have to sleep. see you
<wpwrak> cya ! :)
<kristianpaul> bye
<Fallenou> gn
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
kilae [kilae!~chatzilla@catv-161-018.tbwil.ch] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
mumptai [mumptai!~calle@brmn-4db70ebb.pool.mediaWays.net] has joined #milkymist
elldekaa [elldekaa!~hyviquel@abo-168-129-68.bdx.modulonet.fr] has joined #milkymist
elldekaa [elldekaa!~hyviquel@vpn3.enssat.univ-rennes1.fr] has joined #milkymist
sameeg [sameeg!~leduc@APuteaux-153-1-55-24.w82-124.abo.wanadoo.fr] has joined #milkymist
sh4rm4 [sh4rm4!~sh4rm@gateway/tor-sasl/sh4rm4] has joined #milkymist
Technicus [Technicus!~Technicus@DSLPool-net208-2.wctc.net] has joined #milkymist
<larsc> lekernel: how do we decide whether two actors (or more) can potentially be time-shared? and I do not mean based on the timings but rather on the properties of the Actor
<larsc> do we just generically assume that the same type can always be shared?
<larsc> or do we want to make this overloadable on a per actor type basis