| --- Log opened Sun May 29 00:00:28 2016 | ||
| stekern | olofk: I never got around to make fusesoc stuff for it | 03:28 |
|---|---|---|
| tariq786 | olofk: Are you there? | 12:35 |
| tariq786 | olofk: Are you there? | 12:35 |
| tariq786 | /msg olofk: Hi, Lets chat sometime in private if that is ok with you. | 12:37 |
| tariq786 | msg olofk: Hi, Lets chat sometime in private if that is ok with you. | 12:37 |
| bansvig | stekern: have you seen my yesterday question? could you comment it? | 14:28 |
| stekern | bansvig: nope, what question? | 14:29 |
| bansvig | stekern: Could I made assumption that pipeline have to be stalled (by DU command) before DU-reading various SPR and GPR? | 14:29 |
| stekern | no | 14:30 |
| stekern | or well, maybe you can, but I know that at least profiling makes use of reading npc "on the fly" | 14:31 |
| stekern | that's not a uber critical feature to get 100% right all the time though | 14:32 |
| stekern | it's imprecise anyway | 14:32 |
| stekern | not sure if ther's anything else that relies on reading gprs or sprs on the fly from du | 14:33 |
| bansvig | l.mf(t)spr commands could, I gess | 14:34 |
| stekern | yes, but that's not over the DU interface | 14:34 |
| stekern | l.mf(t)spr commands will stall the pipeline until they are finished | 14:35 |
| bansvig | as far as I understand DU could compete with l.mf(t)spr commands for SPR BUS even so pipeline stalled by l.mf(t)spr, right? | 14:40 |
| bansvig | it looks like DU<->MF(T)SPR arbiter is required to resolve such conflicts | 14:43 |
| bansvig | or alternatively we have to postulate that DU can read/write SPR only if pipeline stalled by DU's command (the approach requires support from SW side) | 14:46 |
| --- Log closed Mon May 30 00:00:29 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!