| wpwrak | wolfspraul: (power from board) we have a perfectly good DC in connector already :) | 00:08 |
|---|---|---|
| kristianpaul | indeed too | 00:11 |
| lekernel_ | Fallenou: yes, you can use a dual ported RAM, they are for free compared to single-ported RAMs in a FPGA | 09:53 |
| lekernel_ | (but cost more in ASIC) | 09:53 |
| 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" | 09:54 |
| lekernel_ | like the "actors" in a CPU do :) | 09:54 |
| larsc | ok | 09:55 |
| larsc | thats probably going to be a bit more context finding actors which can be shared | 09:55 |
| 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 | 09:57 |
| 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 | 09:57 |
| 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 | 09:57 |
| larsc | pipeline delay is a bunch of elements with a sequential delay of one in row | 09:58 |
| lekernel_ | hm, if you have several pipelines in series, it makes a pipeline... not a sequential thing | 10:00 |
| larsc | a buffer has a sequential delay of one | 10:00 |
| larsc | a pipeline are buffers in row | 10:00 |
| 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 | 10:00 |
| lekernel_ | it's the time-shared ones which are interesting | 10:01 |
| lekernel_ | and I'm pretty sure we can generate triggers and everything there, because that's basically what the PFPU system does :) | 10:02 |
| wpwrak | lekernel: already seen this ? http://www.physorg.com/news/2012-01-faster-than-fast-fourier.html | 12:20 |
| wpwrak | paper is here: http://arxiv.org/abs/1201.2501v1 | 12:20 |
| wpwrak | that may be handy for improving our audio processing :) | 12:21 |
| wpwrak | of course, i wouldn't have to implemenet it :) | 12:21 |
| lekernel | nope... thanks, will bookmark it | 12:26 |
| lekernel | of course, i wouldn't have to implemenet it :) <= ?? | 12:26 |
| wpwrak | the math doesn't look too easy | 12:27 |
| wpwrak | but i didn't read it in detail. maybe the nasty bits are just proofs | 12:28 |
| xiangfu | wpwrak, still not finish the static ip address task. now is Chinese new year. the bigger holiday in China. | 15:58 |
| xiangfu | wpwrak, I think I will try to finish that this week. ;) | 15:58 |
| wpwrak | xiangfu: using the big holiday for some quiet work ? ;-) | 16:00 |
| wpwrak | btw, happy new year ! ;-) | 16:01 |
| xiangfu | thanks. happy new year. | 16:01 |
| Fallenou | happy new year :) enjoy have fun! | 16:04 |
| xiangfu | Fallenou, happy new year. | 16:07 |
| Fallenou | thx | 16:12 |
| xiangfu | wpwrak, BTW. the latest daily build make my mouse not working. it more like totally no power. | 16:17 |
| xiangfu | wpwrak, when boot to bios. the mouse still have power. after boot to flickernoise the mouse totally no power at all. | 16:17 |
| wpwrak | hmm, that's odd. i haven't touched that code for weeks. | 16:18 |
| xiangfu | wpwrak, do you have any clue? if easy fix. I can take this task. :D | 16:18 |
| wpwrak | also, in M1rc2/rc3, USB is always powered :) | 16:18 |
| xiangfu | yes. | 16:18 |
| xiangfu | from plug in power cable to bios. all fine. | 16:18 |
| wpwrak | maybe try disconnecting and reconnecting a few times ? i have one mouse that also doesn't always comes up on the first try | 16:18 |
| xiangfu | let me try now. | 16:19 |
| xiangfu | reconnect 10 times. it have power only at the 1 second. then no power at all. | 16:26 |
| wpwrak | hmm. seems that it fails enumeration and then shuts down on its own. | 16:26 |
| wpwrak | do other USB devices work ? | 16:27 |
| xiangfu | wpwrak, keyboard works fine | 16:31 |
| wpwrak | and what version of the USB firmware did you have installed before ? | 16:32 |
| wpwrak | i.e., from what date was the previous RTEMS ? very old ? or recent ? | 16:33 |
| xiangfu | RTEMS 12-01. | 16:37 |
| xiangfu | I am using those files: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01182012-2212/ | 16:37 |
| xiangfu | you can check the VERSIONS: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-01182012-2212/VERSIONS | 16:37 |
| xiangfu | git://git.rtems.org/rtems.git master e493e2a83e8d76079cc84b50a098015492996a3c | 16:37 |
| xiangfu | the last commit at 2011-12-01. :) | 16:38 |
| wpwrak | and from what date was the build you used before ? | 16:38 |
| wpwrak | i.e., the one where the mouse worked ? | 16:38 |
| wpwrak | the last changes to softusb that look like they could affect how the mouse works were from november 30 | 16:43 |
| xiangfu | I will try a early rtems. then let you know the result. | 16:47 |
| xiangfu | have to sleep. see you | 16:47 |
| wpwrak | cya ! :) | 16:48 |
| kristianpaul | bye | 16:48 |
| Fallenou | gn | 16:50 |
| 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 | 23:46 |
| larsc | do we just generically assume that the same type can always be shared? | 23:46 |
| larsc | or do we want to make this overloadable on a per actor type basis | 23:47 |
| --- Tue Jan 24 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!