| --- Log opened Mon Sep 15 00:00:53 2014 | ||
| -!- Netsplit *.net <-> *.split quits: wallento, tariq786, lauri__, fotis2, zama_, jeremy_bennett | 00:13 | |
| -!- Netsplit over, joins: tariq786 | 00:14 | |
| stekern | olofk: I think using the counter makes sense, otherwise it will become inefficient when burst size < fifo size | 03:02 |
|---|---|---|
| stekern | I also think that my 1) claim from yesterday was false, there's just 1 cycle latency on the counter logic, not 2. the second cycle came from that you had fifo_wr and fifo_d registered, which I removed | 03:04 |
| stekern | but I don't understand the read logic in fifo_fwft | 03:07 |
| stekern | well, tbh, there are much in that module I don't understand. ;) | 03:09 |
| stekern | ok, I start to understand, you use three levels of buffers to implement the read-ahead-logic | 03:16 |
| stekern | I think this might fix the problem with the fifo counters I'm seeing: http://pastie.org/9554102 | 03:17 |
| stekern | rebuilding now | 03:17 |
| stekern | well, that !empty is probably bogus too, I think that should be fifo_empty | 03:20 |
| stekern | but, another question, why do you use the fwft fifo for wb_streamer? | 03:25 |
| stekern | I think I've misunderstood the semantics of the 'ready' signal, it's not to latch out data, it's an ack that you've used the data that is on stream_data. | 03:51 |
| stekern | then 'ready' makes sense as a name too | 03:52 |
| stekern | yay! it works! I've got a ~440Hz square coming out of my speakers ;) | 03:53 |
| mor1kx | [mor1kx] skristiansson created withfpu (+11 new commits): https://github.com/openrisc/mor1kx/compare/5687a92e4f35^...131593330158 | 04:45 |
| mor1kx | mor1kx/withfpu 5687a92 bandvig: Initial port of OF32S from OpenRISC-1200... | 04:45 |
| mor1kx | mor1kx/withfpu 67f0644 bandvig: Fix float to integer conversion... | 04:45 |
| mor1kx | mor1kx/withfpu 2d6af6c bandvig: Local list of mor1kx modules | 04:45 |
| olofk | c00l. So it actually works?! | 07:05 |
| olofk | I used an fwft FIFO because it has the same transaction mechanics as AXI4 Stream (and Avalon stream too, I think) | 07:06 |
| olofk | The fwft wrapper itself I found somewhere on the internet | 07:06 |
| olofk | I like the simplicity. Both valid and ready must be active for a successful transmission. That's all there is to it | 07:07 |
| stekern | yeah, I figured that out, that you need a fwft to get the semantics right. It was just that I had misunderstood the semantics of the streamer ;) | 07:08 |
| olofk | Didn't you read the documentation? :) | 07:08 |
| olofk | But if the fifo count isn't delay two cycles, can we remove the wait state from your pastie then? | 07:09 |
| olofk | S_BURST_DONE | 07:09 |
| olofk | Seems to work | 07:10 |
| stekern | yes, this is how my current version looks like: http://pastie.org/9554868 | 07:11 |
| olofk | Seems to work as well | 07:12 |
| olofk | I haven't tried it with different FIFO readout speeds, but at least 10000 buffer reads with different buffer size, start address and burst length seems to work fine | 07:13 |
| olofk | And variable ack delay from the wb memory | 07:14 |
| stekern | you'll need this too: http://pastie.org/9554880 | 07:17 |
| stekern | can you take that patch from there? I don't feel like forking fifo into my github right this second | 07:17 |
| olofk | Sure | 07:18 |
| olofk | You had some updates to the dpram as well. Anything I should update? | 07:19 |
| olofk | Having common stuff like fifo and dpram as submodules in mor1kx would be nice as well, but I guess it might be a bit more overhead for you | 07:20 |
| stekern | tip of the day: wget http://pastie.org/pastes/9554880/download -O ../fwft.patch && git am < ../fwft.patch | 07:22 |
| stekern | yes, you need the new dpram as well | 07:23 |
| olofk | nice | 07:23 |
| olofk | I'll copy that then | 07:23 |
| stekern | don't you need the bypass enabled though? | 07:23 |
| olofk | I have no idea :) | 07:24 |
| stekern | what that does is to output the new written data on the read port when read address == write address | 07:25 |
| olofk | Hmm.. I get errors in my FIFO test bench with the new dpram | 07:25 |
| stekern | I'll admit that one secret reason why I wanted you to update is to get more use coverage of the changes ;) | 07:27 |
| olofk | haha | 07:27 |
| olofk | I'll update my FIFO test bench to get a better feeling for where it fails | 07:27 |
| stekern | it should function the same as the old, the changes are mostly cosmetic | 07:28 |
| olofk | stekern: Need to do some other stuff before I look at the FIFO | 07:49 |
| stekern | no hurry ;) | 07:53 |
| olofk | Like finding where the hell I put an archive that I downloaded | 07:54 |
| olofk | Stupid big hard drives | 07:54 |
| stekern | olofk: you just have too small files | 09:12 |
| stekern | that's why EDA programs are so large, so you will find them easier | 09:13 |
| Hesham | Regarding Cache functions, qemu gives reasonable timing results BTW | 09:31 |
| stekern | really? why? | 09:32 |
| Hesham | Do not know, I tested the Cache test on both or1ksim and qemu. | 09:34 |
| Hesham | or1ksim does not give sensible results as you told me before, the opposite case happens with qemu | 09:34 |
| Hesham | For the same exe | 09:34 |
| Hesham | load 4096 bytes with flush entire data | 09:36 |
| Hesham | duration with normal cache 8986 ns | 09:36 |
| Hesham | duration with warm cache 2421 ns | 09:36 |
| Hesham | duration with flushed cache 2483 ns | 09:36 |
| stekern | well, I wouldn't call that "sensible" cache behaviour | 09:36 |
| stekern | afaik qemu doesn't even try to emulate caches | 09:37 |
| stekern | what you see is probably jus an effect of how qemu does machine translation | 09:37 |
| stekern | since the flushed cache is as fast as the warm cache | 09:38 |
| Hesham | I see | 09:38 |
| Hesham | http://qemu.weilnetz.de/qemu-tech.html#Translation-cache Does this apply for all architectures including or32? A higher level maybe? | 09:43 |
| stekern | yes | 09:45 |
| -!- _franck_ is now known as _franck__ | 10:06 | |
| olofk | SDR is fun! Still haven't got a clue what all the different graphs mean though, but they are pretty | 10:11 |
| stekern | this is from the wikipedia page about SDR: http://en.wikipedia.org/wiki/Software-defined_radio#mediaviewer/File:Perseus_SDR_receiver.jpg | 10:17 |
| stekern | I don't think that's a good choice of name in Finland | 10:17 |
| stekern | perse == ass | 10:17 |
| olofk | :) | 10:21 |
| stekern | hmm, the arg to isr handler change from void * to uint32_t in the or1k support code was IMO a bit unfortunate... | 12:29 |
| stekern | olofk: I've added an irq to the writer as well now, I've connected it to bit 1 of reg 0 | 12:37 |
| stekern | http://pastie.org/9555464 | 12:39 |
| stekern | seems to work fine | 12:39 |
| olofk | cool | 12:56 |
| olofk | Maybe you should fork after all. I have way too many pasties to test now :)( | 12:56 |
| olofk | s/(/ | 12:56 |
| stekern | I'll try to put something together ;) | 13:02 |
| olofk | What should I hook up to re in the dpram? | 13:26 |
| olofk | I just set it to '1' and now it passes the FIFO regression tests again | 13:34 |
| olofk | With your updated dpram and fifo_fwft patch | 13:34 |
| olofk | Doh.. there's no support for float plusargs in fusesoc | 13:36 |
| olofk | ahh. but strings work just as well | 13:39 |
| olofk | But it looks like there are problems when I write to the fifo faster than I can read | 13:40 |
| stekern | olofk: you should connect it like it's connected in the storebuffer | 13:41 |
| poke53282 | Finally I got around 5 ms sound output. | 16:36 |
| poke53282 | But the sound device sends the stream with a samplerate of 96000 over the bus. Is this a usual quantity nowadays. I stopped reading about this after the CD which had 44100. | 16:38 |
| stekern | I think it depends, but I send data to the i2s device at 96khz | 16:42 |
| poke53282 | Hmm, HD content use this rate. | 16:44 |
| poke53282 | Then it's true. | 16:45 |
| poke53282 | I use PIO to a FIFO at the moment instead of DMA. | 16:45 |
| poke53282 | So, maybe I should reduce this rate. | 16:47 |
| dalias | there's no point in 96khz audio | 16:47 |
| dalias | 48khz is the highest that makes sense | 16:47 |
| poke53282 | audiophiles might have a different opinion about that :) | 16:49 |
| dalias | well their opinion is invalid until they sit down for a double-blind test | 16:49 |
| stekern | I agree, but iirc it was easiest to generate for this chip | 16:50 |
| dalias | btw 96khz sampling actually arguably has WORSE quality | 16:50 |
| stekern | I have crappy ears, so 44100 was certainly good enough for me | 16:51 |
| dalias | https://xiph.org/~xiphmont/demo/neil-young.html | 16:51 |
| dalias | has nothing to do with your ears being crappy | 16:51 |
| poke53282 | I wonder whether all this matters if you have compressed sound. Probably not. | 16:52 |
| poke53282 | 16 Bits persample is also quiet high. I wonder if my magnet in my sound box can differ between 65536 positions. | 16:54 |
| poke53282 | And now we have 24 bits or even floating point numbers. | 16:55 |
| stekern | the i2s chip I'm using is 32 bits | 17:00 |
| poke53282 | I am pretty sure that in my audio equipment is no 32 bit DA converter implemented. | 17:02 |
| poke53282 | If they use the output of +- 1 Volt to my loud speaker, that means they try to differ in the nano-Volt region. | 17:04 |
| poke53282 | It makes sense in audio software for calculations of course. | 17:04 |
| dalias | 16bit is actually rather low | 17:06 |
| poke53282 | dalias: so they argue about hardware limitations and distortions because of the limitations. | 17:07 |
| dalias | it lacks dynamic range | 17:07 |
| dalias | a 16-bit logarithmic scale would be fine | 17:07 |
| poke53282 | the article says, that 16 bits is Ok. | 17:09 |
| poke53282 | the Javascript audiocontext takes floating point numbers between -1 and 1. | 17:10 |
| poke53282 | Yesterday I tried different values (like NaN) with the result, that I had to reset my sound card. Never had this problem before. | 17:11 |
| poke53282 | Yes, I can break the specific sound card just by opening a web site. | 17:12 |
| poke53282 | Maybe I should write a bug report. | 17:12 |
| poke53282 | Dalias: Thanks for the article. It makes several thinks clear. | 17:15 |
| dalias | :) | 17:25 |
| olofk | poke53282: Haha. That's a new attack surface then. If you hear a radio station that plays really bad music, you could convince them to try out jor1k and hopefully break their equipment ;) | 18:28 |
| poke53282 | I already fixed the bug. But I think this can easily reproduced with a few lines of code. | 18:45 |
| poke53282 | For me a simply reset of my sound card driver fixed it. | 19:16 |
| Hesham | Can I use -fstack-protector* flag for the current gcc port? | 19:56 |
| stekern | compiling tinysid with anything > O0 makes it not work | 20:28 |
| poke53282 | hmm, that's strange. | 20:38 |
| poke53282 | so, has nothing to do with endianess and alignment | 20:39 |
| poke53282 | the cpu has a 16 bit address-bus and is capable to do non-aligned accesses. | 20:40 |
| poke53282 | ok, the databus is 8 Bit. But the instructions are non-aligned. | 20:41 |
| poke53282 | But the source code seems to take care of it. | 20:42 |
| stekern | yes, it does | 20:42 |
| poke53282 | maybe the fixedpoint math? | 20:42 |
| stekern | well, we are probably looking at different tinysids | 20:43 |
| poke53282 | https://github.com/robn/tinysid | 20:43 |
| stekern | I just remembered that you pasted a link to another tinysid | 20:43 |
| stekern | yes, that's not the one | 20:43 |
| poke53282 | But this is an error you should investigate. | 20:44 |
| stekern | http://git.rockbox.org/?p=rockbox.git;a=blob;f=lib/rbcodec/codecs/sid.c;h=6e39d3f759c92a99bad73f7aac3727c43cca2a0f;hb=HEAD | 20:45 |
| poke53282 | that's all? | 20:46 |
| stekern | yes | 20:46 |
| poke53282 | I can't see anything unusual in the code. | 20:51 |
| stekern | yeah, it's not 8086tiny:ish ;) | 20:53 |
| poke53282 | Maybe you should valgrind it. There might be a bug. Otherwise I don't see a reason why it should not work when you turn on -O2 | 20:53 |
| poke53282 | static inline int quickfloat_ConvertFromFloat(float f) { return (int)(f*(1<<16)); } | 21:17 |
| poke53282 | ... | 21:17 |
| poke53282 | filtmul = quickfloat_ConvertFromFloat(21.5332031f)/mixfrq; | 21:17 |
| poke53282 | he uses also strange conversions. Could this be a reason? | 21:17 |
| poke53282 | static inline int quickfloat_Multiply(int a, int b) { return (a>>8)*(b>>8); } | 21:19 |
| poke53282 | this is strange enough for me | 21:19 |
| poke53282 | Might be, that he assumes some special C behavior or some undefined behavior in C which works just fine on x86. | 21:20 |
| poke53282 | there are some examples about C optimizations which are unexpected but according to the standard valid. | 21:23 |
| -!- Netsplit *.net <-> *.split quits: martinboehnert | 23:52 | |
| -!- Netsplit over, joins: martinboehnert | 23:54 | |
| --- Log closed Tue Sep 16 00:00:54 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
