| --- Log opened Wed Sep 17 00:00:56 2014 | ||
| poke53282 | My plan for tonight is, to increase the time of reasonable sound output from 5 ms to 10ms :) | 00:38 |
|---|---|---|
| -!- Netsplit *.net <-> *.split quits: simoncook, rah, mboehnert, knz, olofk, xlro | 01:48 | |
| -!- Netsplit over, joins: mboehnert | 01:54 | |
| -!- Netsplit over, joins: simoncook, rah, knz, olofk, xlro | 01:54 | |
| stekern | olofk: I'm experiencing a regression after I pulled the latest wb_streamer stuff, and I see full & wr_en asserted at the same time, so I suspect that it's this: https://github.com/olofk/wb_streamer/commit/52bd8abacbcd9049600f8d0f8273259433b04a44 | 03:14 |
| stekern | ...but I think that <= should be correct though, so the root cause might be somewhere else | 03:16 |
| olofk | hmm.. I wonder how to get this behaviour in the test bench | 05:19 |
| stekern | in my setup, writing is many magnitudes faster than writing | 05:23 |
| stekern | than reading | 05:23 |
| olofk | cool. I'll start with that | 05:24 |
| stekern | I had some more observations, wait I'll call them back from the back of my brain | 05:25 |
| stekern | hello? ..ello? ..ello? | 05:25 |
| olofk | Oh my god! It's full of stars! | 05:26 |
| olofk | What's your register settings? | 05:27 |
| olofk | burst size, buf size.. | 05:27 |
| stekern | burst size = 8, buf size = 64 KB, FIFO_AW = 10 | 05:33 |
| olofk | cool | 05:33 |
| olofk | I found another set of params that seem to break the sim. I'll try those first | 05:33 |
| olofk | hmm.. the IRQ line is never raised | 05:35 |
| stekern | it is in my setup at least | 05:43 |
| stekern | I can rebuild with the <= and give you a capture of the failure | 05:45 |
| olofk | Great | 05:45 |
| poke53282 | no luck today. No sound output | 06:05 |
| olofk | Doh. Just realized why my test bench doesn't work | 06:45 |
| stekern | olofk: http://oompa.chokladfabriken.org/openrisc/wb_streamer_debug.vcd | 07:02 |
| stekern | hmmm... why is cnt only 5 bits? | 07:07 |
| olofk | That's a good question. FIFO_AW = 10 | 07:08 |
| stekern | ah, it's just because signal tap doesn't update what you log just because the size changes | 07:10 |
| olofk | ah ok | 07:10 |
| stekern | I think it's safe the all the bits that we can't see is '1' | 07:11 |
| stekern | *safe to assume | 07:11 |
| stekern | I think I know what the problem is though, cnt can't hold 2**FIFO_AW | 07:15 |
| olofk | True | 07:23 |
| olofk | stekern: When I lower the readout speed if the FIFO it gets stuck here as well | 07:45 |
| olofk | ehmmm. how do I take a screenshot in X? | 07:46 |
| LoneTech | olofk: many options, for instance using graphicsmagick: import -screen filename.png | 07:47 |
| olofk | Found xfce4-screenshooter | 07:47 |
| olofk | LoneTech: Thanks. I didn't have graphicsmagick installed though, so I'm going with xfce4-screenshooter | 07:48 |
| olofk | stekern: I think you might be right regarding cnt https://www.dropbox.com/s/6a4lqo3dkomw4dx/Screenshot%20-%202014-09-17%20-%2009%3A49%3A25.png?dl=0 | 07:50 |
| stekern | olofk: I'm doing a build with [DEPTH_WIDTH:0] cnt now | 07:54 |
| stekern | and the same change in the writer | 07:55 |
| olofk | I tried that too | 08:00 |
| olofk | Still seems to be a problem somewhere | 08:01 |
| olofk | There is still a write when FIFO is full | 08:02 |
| olofk | Actually I think the problem just moved | 08:03 |
| stekern | yes, I've got that too | 08:05 |
| olofk | The full flag is actually set on 2^AW-1 | 08:06 |
| olofk | So maybe the <= statement in ctrl is wrong after all | 08:06 |
| olofk | Or should be <= 2**FIFO_AW-1 (which is the same thing) | 08:06 |
| stekern | hmm, but the FIFO should be able to hold 2^FIFO_AW entries | 08:07 |
| olofk | Yeah, I realized that too | 08:07 |
| stekern | why is it then signaling full "too early" | 08:08 |
| olofk | Don't know | 08:08 |
| olofk | Might be the part that I added :) | 08:08 |
| stekern | what did you add? | 08:08 |
| stekern | might be that the storebuffer fifo signals off-by-one | 08:08 |
| olofk | Could be. I suspected the fifo_fwft | 08:09 |
| olofk | But I see now that full is coming directly from the fifo | 08:09 |
| stekern | it wouldn't matter in mor1kx if it did, since writes are pushed back on full | 08:09 |
| olofk | No, it only matters in this case since we are relying on the fifo count | 08:10 |
| olofk | And assume that the FIFO can hold the new data | 08:11 |
| olofk | Actually, we're not using the full flag at all | 08:11 |
| olofk | In my case, I have burst size=8 and FIFO depth is 32 | 08:13 |
| olofk | FIFO starts to fill up when there are 24 entries left. So far so good | 08:13 |
| olofk | Yep. There is something fishy in fifo or fifo_fwft | 08:17 |
| olofk | I fucking hate FIFOs. | 08:19 |
| olofk | Manually counted all writes and reads, and the counter seem to be consistent, so I suspect fifo.v right now | 08:31 |
| olofk | write_pointer == "where to write next entry" and read_pointer == "address of next data to read" = | 08:32 |
| olofk | ? | 08:32 |
| olofk | Cheating a bit and looking at other FIFOs, they all seem to use an internal counter | 08:44 |
| olofk | Might have to do that. I think that read_pointer == write_pointer for both the empty and full conditions | 08:44 |
| olofk | Found another solution now where the pointers are one bit wider, and MSB is used to detect empty or full | 08:47 |
| olofk | Looks like this works http://pastebin.com/1PnAUZ7k | 09:01 |
| olofk | A few lines shorter http://pastebin.com/Sn3RjRRs | 09:07 |
| stekern | that has the added benefit that you get rid of the prev_read_pointer | 09:19 |
| olofk | yep | 09:19 |
| olofk | So it might even save a few flops | 09:19 |
| stekern | I'll do some tests with mor1kx | 09:20 |
| olofk | It works in my tb now, but doesn't seem to guarantee anything, so I'm holding off pushing the patch until then | 09:20 |
| olofk | Time to pick up baby | 09:20 |
| olofk | Does anyone want to consider themself as a maintainer for the de0_nano FuseSoC port? | 10:28 |
| olofk | I'm basically want to commit some patches and wonder if anyone want to comment on them | 10:29 |
| * stekern feel like olofk's staring at him | 10:47 | |
| stekern | olofk: I still get we & full conditions with the code you pasted | 10:51 |
| olofk | Hmm.. | 10:57 |
| olofk | I never looked explicitly for that | 10:57 |
| olofk | Did you update the streamer? | 10:58 |
| olofk | I can take a look at it. Just need to do some other patches first | 10:59 |
| olofk | My orpsoc-cores working tree is a mess right now | 10:59 |
| stekern | you only have one orpsoc-cores working tree that's a mess? lucky bastard | 11:06 |
| olofk | :) | 11:10 |
| olofk | done | 11:11 |
| olofk | Hmm.. can't make that happen here | 11:14 |
| olofk | full & we | 11:14 |
| olofk | Did you increase the cnt signal everywhere as well? | 11:15 |
| stekern | mmm | 11:15 |
| olofk | I have a local change that increases it in fifo_fwft module port | 11:15 |
| stekern | mmm, so do I | 11:17 |
| stekern | it's signaling full when cnt = 0x20 | 11:19 |
| stekern | but the fifo should be 2^10 | 11:20 |
| olofk | hmm | 11:20 |
| stekern | I'll bring in the read/write pointers into the signaltap | 11:20 |
| olofk | Can you look at the synthesis logs (or send them over to me) | 11:21 |
| olofk | Want to ensure that FIFO_AW is set correctly | 11:21 |
| stekern | both the read and write pointer are 10 bits, so I think it should be | 11:22 |
| olofk | That's even weirder | 11:22 |
| stekern | I mean 11 bits | 11:23 |
| stekern | 10:0 | 11:23 |
| olofk | Looking at the pointers will be very interesting | 11:24 |
| olofk | I wonder if the counter gets out of sync | 11:28 |
| stekern | area wise it didn't make much difference, a couple of more LUTs and a couple of less regs | 11:30 |
| olofk | Sounds reasonable | 11:31 |
| stekern | write_pointer == 0x410 and read_pointer == 0x010 | 12:07 |
| stekern | oh, but the cnt value I said before was wrong... signaltap had added cnt[10] and cnt[4:0] to the bus... | 12:15 |
| stekern | ok, now this makes more sense. it's 0x400 | 12:48 |
| stekern | so it has wrapped around | 12:48 |
| stekern | or not wrapped around, it's what it should be | 12:49 |
| stekern | ok, I found the reason, I had forgot to save the change of the cnt wire in the writer top module... | 14:01 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/1db1b36654d3620d62d2def58af0329c17121c48 | 14:06 |
| mor1kx | mor1kx/master 1db1b36 Stefan Kristiansson: store_buffer: fix full_o signaling... | 14:06 |
| olofk | It works now? | 14:15 |
| stekern | I'm still building, but I'm fairly certain that that's it | 14:17 |
| stekern | and I'm confident that your fix to the fifo full signal is correct | 14:18 |
| stekern | I gave you some creds in the commit msg btw ;) | 14:19 |
| stekern | ...so you can stop thinking that I'm a douchebag that hurried out that commit to make it look like you based your fix on my commit instead of the other way around =P | 14:20 |
| olofk | Haha | 14:26 |
| olofk | I was prepared for that, so I installed a back door in the code | 14:26 |
| stekern | I noticed, that's why I changed it slightly | 14:27 |
| stekern | it works now | 14:27 |
| olofk | c00l | 14:27 |
| olofk | Hmm.. might need to go to work tomorrow. It's difficult to analyze RF signals without a spectrum analyzer | 14:28 |
| olofk | Even if you have a really really fast multimeter | 14:29 |
| _franck__ | FYI: building the current or1k-src repo without --disable-werror on a 64bits machine trigger an error. The solution is here: https://sourceware.org/ml/binutils/2014-01/msg00334.html | 15:35 |
| _franck__ | so, for now --disable-werror is required for 32-bits _and_ 64-bits machines | 15:36 |
| _franck__ | (unlike it is said on the wiki) | 15:36 |
| poke53282 | olofk: I was wrong. Framebuffers supports mode setting. But not the ocfb | 16:13 |
| rjo | sb0_: regarding all these environment variables, i think its better if scripts just let artiq populate an ArgumentParser with artiq options (-v, --dump...). | 16:36 |
| rjo | damn. wrong channel. | 16:36 |
| -!- Netsplit *.net <-> *.split quits: ed-jones | 17:00 | |
| stekern | _franck_: FYI, building binutils from upstream doesn't have that problem (neither on 32-bit nor 64-bit) | 17:00 |
| -!- Netsplit *.net <-> *.split quits: O01eg | 17:00 | |
| -!- Netsplit over, joins: ed-jones | 17:00 | |
| -!- Netsplit *.net <-> *.split quits: jeremypbennett, poke53282, rjo | 17:01 | |
| stekern | or umm, I thought you were referring to something else... scratch what I said | 17:01 |
| -!- Netsplit over, joins: O01eg, jeremypbennett, poke53282, rjo | 17:02 | |
| -!- Netsplit *.net <-> *.split quits: bentley` | 17:02 | |
| -!- Netsplit over, joins: bentley` | 17:03 | |
| stekern | _franck_: can you elaborate, what in the ml message is the solution? and what is the problem? | 17:03 |
| _franck_ | stekern: I should have been less affirmative. I had this error: https://sourceware.org/ml/binutils/2014-01/msg00323.html | 18:35 |
| _franck_ | then later in the thread it says that the patch I linked here is the solution | 18:35 |
| _franck_ | however, the only thing I did is to add --disable-werror to make it work | 18:36 |
| stekern | but, haven't those been committed to upstream? | 18:40 |
| _franck_ | may be, I don't know, I used or1k-src from github | 18:40 |
| _franck_ | that might be the problem | 18:40 |
| stekern | (which in no way makes your claim that or1k-src might need the --disable-werror false) | 18:41 |
| stekern | but I built binutils from or1k-src about a week ago without that flag | 18:42 |
| _franck_ | it may depend on the version of GCC used to compile binutils | 18:43 |
| stekern | oh, right... sorry, it said with 4.9.x in the msg you pasted | 18:48 |
| stekern | I've got 4.8.2 | 18:48 |
| poke53282 | Arghh, looks like the whole sound output is more complicated than expected. Maybe I have to change more than expected. | 21:23 |
| poke53282 | I found something funny: | 21:24 |
| poke53282 | #define SNDRV_PCM_RATE_CONTINUOUS (1<<30) /* continuous range */ | 21:24 |
| poke53282 | #define SNDRV_PCM_RATE_KNOT (1<<31) /* supports more non-continuos rates */ | 21:24 |
| poke53282 | what's this? | 21:24 |
| poke53282 | stekern: Did you ever compile a native gdb? | 22:35 |
| poke53282 | or ltrace? | 23:31 |
| poke53282 | well, the answer you will give to me is pretty obvious. But one has asked me if I can compile this tools. | 23:54 |
| --- Log closed Thu Sep 18 00:00:57 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
