| --- Log opened Mon Nov 10 00:00:21 2014 | ||
| olofk | poke53282: Haha. I have always wondered what that curved squre thing is on my keyboard :) | 09:13 |
|---|---|---|
| olofk | ¤ | 09:16 |
| -!- jeremy_bennett is now known as jeremybennett_ | 09:19 | |
| olofk | maxpaln: I just took a look at your wb_bfm changes | 10:00 |
| olofk | I actually got the exact same idea as you did yesterday to keep the 2d arrays as regs in wb_bfm_master instead of sending them through the functions :) | 10:01 |
| olofk | But I would like to split things up a little differently. You can only send random data with a burst_write with your changes. We still need to be able to send user-defined data | 10:03 |
| olofk | Same with read | 10:03 |
| olofk | I would like to rename your read_burst implementation to something like "verify" or "read_and_verify", and make the ordinary read_burst omit the data_compare | 10:05 |
| olofk | So writes would be 1. Fill write buffer in wb_bfm_master. 2. Call Write function | 10:06 |
| maxpaln | hi olofk: sounds good | 10:26 |
| maxpaln | I had a few additional thoughts over the weekend. | 10:27 |
| maxpaln | I realised that setting subtransactions to 0 gets very close to the original simple write-then-read functionality. A slight modification to the generation of the transaction initialisation (from a fixed linear burst of length MAX_BURST_LEN to a random burst of random length) would allow the same function to offer both sets of functionality. I see this as a relatively simple change. | 10:28 |
| maxpaln | Secondly, I think the addition on the wait states could be better | 10:29 |
| maxpaln | the deassertion of stb/cyc etc. is still in the write_burst function but the number of waits inserted is managed by the 'insert_wait_states' function. These should be coupled together - and the insert_wait_states called from within the write_burst or read_burst function I think. | 10:30 |
| maxpaln | I may have a bit of time to revisit this later today - out of interest, how does the user specify the data to be sent? | 10:32 |
| olofk | maxpaln: The original read_burst takes a flattened data array as one of its inputs | 10:41 |
| olofk | sorry, write_burst | 10:41 |
| olofk | and read_burst outputs a flattened array | 10:41 |
| maxpaln | oh, I see - so the idea would be to maintain the old and new versions of these functions | 10:47 |
| maxpaln | what about having a further function that accepts a flattened array as its input - this function could populate the write_data 2d array with the users data. This would allow new functions to be used with a little modification to choose between random and user data. | 10:52 |
| Hesham | wallento: A quick question, does optimsoc uses or1k as processor tiles? | 10:52 |
| Igor_Unibo | Hey there. This is Igor Loi from Univ of Bologna. | 10:58 |
| Igor_Unibo | I have some questions about Espresso ProntoEspresso and cappuccino version of the core | 10:59 |
| olofk | Igor_Unibo: Hi. Ask away | 11:00 |
| Igor_Unibo | I am working with davide rossi and Antonio Pullini (the guys that ere at the openrisc conference) | 11:01 |
| Igor_Unibo | I a running some synthesis to compare our version with the cappuccino , espresso and prontoespresso | 11:01 |
| Igor_Unibo | and i was also running some test | 11:01 |
| Igor_Unibo | In the espresso and prontoespresso i have some issues | 11:01 |
| olofk | Igor_Unibo: The *espresso cores haven't been updated much lately, so they are likely to contain bugs unfortunately | 11:02 |
| olofk | juliusb and stekern knows most about this though | 11:02 |
| Igor_Unibo | ok, cappuccino seems fine | 11:03 |
| Igor_Unibo | i mean it pass the test i made | 11:03 |
| Igor_Unibo | But for this core i have a question. The cores seems to big, and looking in the synthesis report i see that the store buffer is consuming most of the area. | 11:04 |
| Igor_Unibo | It uses 8 slot, 100Flip flop each, and i am wondering why this fifo is there and if can be removed | 11:04 |
| olofk | maxpaln: My idea is slightly different. Flattened arrays are a pain to work with as you need to deserialize them in the calling functions. I think that we should have the 2d array inside of the bfm. For writes we let the caller fill it up with data before calling write_burst | 11:05 |
| olofk | Igor_Unibo: Yes, you can remove the store buffer by setting the parameter FEATURE_STORE_BUFFER to "NONE" | 11:06 |
| olofk | maxpaln: So wb_bfm_transactor will be responsible for setting the data to $random before calling write_burst | 11:07 |
| Igor_Unibo | Ok this make sense now | 11:07 |
| olofk | maxpaln: And other users of wb_bfm_master can set it to whatever they want | 11:08 |
| Igor_Unibo | Thanks for the clear explanation | 11:09 |
| olofk | Igor_Unibo: No problems. Happy to help | 11:09 |
| stekern | Igor_Unibo: the storebuffer is there to avoid the pipeline to stall on stores | 11:13 |
| Igor_Unibo | Hello Stekern. Thanks, Now is clear why is there. As you know we are comparing cappuccino with or10n our version of the openrisc, and i want to compare cores with similar features | 11:15 |
| stekern | right, and I believe in the use case for or10n, you have tightly coupled memories, so stores should be fairly quick anyway | 11:17 |
| Igor_Unibo | yep exactly | 11:17 |
| Igor_Unibo | we have atomic accesses (single read or single write), and the actual protocol introduces some bubbles, because the data_ack_i is sampled | 11:19 |
| stekern | I can make a note about cappuccino in that regard, it's designed to be used with "slow" memories, so using it without caches will degrade its performance | 11:19 |
| Igor_Unibo | i am looking how to have 1 store or 1 read per cycle | 11:19 |
| Igor_Unibo | Yes i saw it | 11:19 |
| stekern | it could be possible to exchange the caches with memories that always signal a hit | 11:21 |
| stekern | at least for a instruction ROM that'd work straight out of the box | 11:22 |
| Igor_Unibo | well the main difference is that our data memory is shared | 11:24 |
| Igor_Unibo | so we must arbitrate each request | 11:24 |
| Igor_Unibo | instr cache is fine | 11:24 |
| stekern | Igor_Unibo: btw, if you have some testcase that breaks *espresso, feel free to share and I can take a look at it | 11:28 |
| Igor_Unibo | well the issue in espresso and pronto_espresso is during the boot | 11:29 |
| Igor_Unibo | maybe is a stupid mistake i made | 11:29 |
| Igor_Unibo | anyway when i enter in the _start section, during the BSS clearing | 11:29 |
| Igor_Unibo | ENTRY(_start) | 11:29 |
| Igor_Unibo | /* Cache initialisation */ | 11:29 |
| Igor_Unibo | l.jal _cache_init | 11:29 |
| Igor_Unibo | l.nop | 11:29 |
| Igor_Unibo | l.jal flagsInit | 11:29 |
| Igor_Unibo | l.nop | 11:29 |
| Igor_Unibo | /* Clear BSS */ | 11:29 |
| Igor_Unibo | LOAD_SYMBOL_2_GPR(r5, _bss_start) | 11:29 |
| Igor_Unibo | LOAD_SYMBOL_2_GPR(r6, _bss_end) | 11:29 |
| Igor_Unibo | 1: | 11:29 |
| Igor_Unibo | l.sw (0)(r5), r0 | 11:29 |
| Igor_Unibo | l.sfltu r5, r6 | 11:29 |
| Igor_Unibo | the branch loops forever, never exits | 11:30 |
| Igor_Unibo | the last instruction is never executed | 11:31 |
| Igor_Unibo | so the core clears only the first lcation of the BSS | 11:31 |
| stekern | I think there are a couple of instructions missing in what you pasted | 11:32 |
| stekern | pastie.org or something is usually more suitable for pasting when the code is more than 1-3 lines | 11:33 |
| Igor_Unibo | sorry i didn't know | 11:35 |
| Igor_Unibo | 1 | 11:35 |
| Igor_Unibo | 2 | 11:35 |
| Igor_Unibo | 3 | 11:35 |
| Igor_Unibo | 4 | 11:35 |
| Igor_Unibo | 5 | 11:35 |
| Igor_Unibo | sorry i have been disconnected | 11:36 |
| Igor_Unibo | i am not familiar with IRC | 11:37 |
| Igor_Unibo | sorry for that | 11:37 |
| stekern | no worries | 11:37 |
| Igor_Unibo | the link is this one | 11:37 |
| Igor_Unibo | http://pastie.org/9709299#10 | 11:37 |
| Igor_Unibo | in cappuccino line 15 is executed in the delay slot i guess | 11:38 |
| maxpaln | olofk: but isnt this where we started - if bfm_transactor sets the write_data 2d array, how does the write_burst task in bfm_master access the data? | 11:38 |
| stekern | pronto_espresso doesn't have a delay slot, so for that, you'd have to swap line 14 and 15 | 11:38 |
| stekern | but if you see the same problem in espresso, then that's weird | 11:38 |
| Igor_Unibo | let me try again and then i came back to you | 11:39 |
| olofk | maxpaln: Something like this. for(i=0;i<LEN;i=i+1) bfm.write_data[i]=$random; write_burst(t_address, t_address, 4'hf, MAX_BURST_LEN, LINEAR_BURST, err); | 11:45 |
| maxpaln | Ah, I forgot that Verilog allows accessing of signals across the hierarchy. | 11:46 |
| maxpaln | a handy thing for test fixtures! :-) | 11:47 |
| maxpaln | ok, so essentially the change is to move the population of the write_data 2d array back into bfm_transactor and allow write_burst to access it via a hierachical reference. | 11:49 |
| olofk | maxpaln: Yes, and then we can remove the 1d data array argument from the original write_burst function | 12:16 |
| olofk | Or perhaps keep it for backwards compatibility and give the data-less function a new name | 12:16 |
| olofk | Nahh.. we don't need backwards compatibility. | 12:17 |
| stekern | yeah, how'd we know about our users if we don't give anything to complain about ;) | 12:19 |
| olofk | :) | 12:19 |
| olofk | Actually, I can't find any users of the write_burst function outside of wb_bfm | 12:28 |
| olofk | stekern, _franck_, other people: How much work is it to add the vga_lcd IP? Do I need to set up any board-specific stuff? | 12:35 |
| stekern | it's not much more work than any other peripheral with a wb master | 12:37 |
| olofk | great | 12:37 |
| stekern | -much | 12:37 |
| stekern | you want a dedicated interface to the MC for it though, since it's bw hungry | 12:38 |
| olofk | Got it | 12:38 |
| poke53282 | olofk: Yes, you can finally create filenames with this sign in jor1k. A missing features everyone is waiting since a long time. ;) | 17:03 |
| poke53282 | The original reason is, that my filesystem will be used in https://github.com/copy/v86 to run big distributions like Archlinux. So we supported each other to fix bugs and to add missing features in the filesystem. | 17:06 |
| olofk | poke53282: cool. Good that you can share code like that | 17:12 |
| olofk | And that missing sign was the only thing that held me back from using jor1k as main main computer | 17:13 |
| stekern | ¤? | 17:17 |
| poke53282 | olofk: On a Chromebook I guess. Future mobile computers will just boot into a web browser. So the only way having Linux will be this ;) | 17:21 |
| poke53282 | Yes, this sign stekern. Later when I zoomed in I saw, that it is a circle. | 17:22 |
| poke53282 | I don't have it on my keyboard here. But I like that you have the Å sign on your keyboard. Do you know how often I have to write Ångström every week? | 17:23 |
| olofk | haha | 17:26 |
| poke53282 | Ahh, the developer edition of Firefox was released today. But I guess, I still don't get the assembler output of the compiled Javascript. So, not really useful. | 17:30 |
| olofk | ysionneau, sb0 : I want to look at the verilog for the S6DDRPhy for inspiration, but I can't make migen spit out verilog for me. Which obvious stupdid mistake did I make? ;) | 17:38 |
| ysionneau | please poste your python file and error :) | 17:39 |
| ysionneau | post* | 17:39 |
| olofk | http://pastie.org/9710016 | 17:39 |
| ysionneau | thx | 17:39 |
| ysionneau | you just forgot print() | 17:40 |
| ysionneau | :) | 17:40 |
| ysionneau | print(verilog.convert(m)) | 17:40 |
| olofk | http://pastie.org/9710018 | 17:40 |
| olofk | There's something else | 17:40 |
| ysionneau | oh | 17:40 |
| olofk | I just picked a random platform btw | 17:41 |
| ysionneau | mixxeo and m1 should work for S6DDRPHY | 17:41 |
| ysionneau | even if on those board it's DDR and not DDR2 that should print you verilog | 17:41 |
| olofk | Yeah, I was hoping for that | 17:42 |
| olofk | Can you try it on your installation? | 17:43 |
| ysionneau | sure | 17:44 |
| ysionneau | I've got the same issue | 17:45 |
| olofk | I got it now | 17:45 |
| olofk | dqs_ddr_alignment must be a string or int | 17:46 |
| olofk | It gets translated to a parameter | 17:46 |
| stekern | what did you use, an imaginary number? | 17:46 |
| ysionneau | None <- | 17:47 |
| ysionneau | :p | 17:47 |
| olofk | I used ¤ of course | 17:47 |
| ysionneau | olofk: I'm using "C1" in my simulation of S6DDRPHY | 17:47 |
| olofk | All my variables are called ¤1, ¤2, ¤3 etc | 17:47 |
| stekern | ah, didn't think about that | 17:47 |
| ysionneau | as a value for dqs_ddr_alignment | 17:47 |
| olofk | ysionneau: Yeah, I suspect it some tech-specific parameter for the SERDES or DDR FFs | 17:48 |
| ysionneau | yes | 17:48 |
| ysionneau | you can put "C0" or "C1" or "NONE" but here anyway since you don't simulate you can put whatever string you want :p | 17:49 |
| olofk | Jesus. Looking at the verilog code was a very bad idea :) | 17:51 |
| ysionneau | héhé | 17:52 |
| ysionneau | enjoy the OSERDES2 ISERDES2 ODDR2 and stuff | 17:52 |
| olofk | Mmm... and that's only a small part of the 2795 lines | 17:53 |
| ysionneau | so many? | 17:53 |
| ysionneau | a "complete" design with a ddr controller + this PHY and wishbone stuff gives me 1387 lines total | 17:54 |
| olofk | Yeah, I wonder if it included the MC as well | 17:54 |
| olofk | hmm | 17:54 |
| ysionneau | according to your python paste, only the PHY :o | 17:55 |
| ysionneau | weird | 17:55 |
| ysionneau | shouldn't be that long | 17:55 |
| olofk | oh well. Got to run. | 17:57 |
| ysionneau | see ya! | 17:57 |
| poke53282 | stekern: One question. gcc is always some sort of randomizing the instructions to get as much independent instructions as possible together. However this leads to cases, in which stack and frame pointer are updated pretty late. Is this a problem if some instruction fail like memory accesses? Especially for debugging, but also for unwinding. So you know the optimization flag for this behavior? | 18:40 |
| poke53282 | Just a small example: http://pastie.org/9710123#8 | 18:46 |
| poke53282 | l.mul is executed first. What would happen if l.mul would be l.div and would raise a division by zero? | 18:47 |
| stekern | nothing, since we have the red zone | 18:47 |
| stekern | that save of r1 is completely bogus btw | 18:48 |
| poke53282 | Yes, there is a comment in the c compiler. They always force to save r1 because of a unwinding problem I think. | 18:49 |
| stekern | yes, it's a workaround for some dwarf thing | 18:49 |
| poke53282 | I would like to investigate this if I would have a second live :) | 18:49 |
| stekern | they = blueCmd ;) | 18:49 |
| * blueCmd twitches | 18:50 | |
| blueCmd | yeah something like that | 18:50 |
| poke53282 | But what about try catch blocks and longjumps? | 18:52 |
| poke53282 | They are all save with such a behavior? | 18:53 |
| poke53282 | s/save/safe/ | 18:54 |
| stekern | longjumps has it own context save, so that should be safe I think | 18:59 |
| stekern | to be honest, I'm not sure how dwarf exception handling works | 19:01 |
| poke53282 | -fno-schedule-insns2 | 19:09 |
| poke53282 | This one seems to be responsible flag. | 19:10 |
| poke53282 | I don't know either stekern. | 19:10 |
| olofk | jeremybennett: Any news on the last GCC contributor btw? | 19:11 |
| poke53282 | Maybe I should run the testsuite removing this optimization. Just to be sure. | 19:15 |
| poke53282 | Here another example: http://pastie.org/9710197 | 19:34 |
| poke53282 | He executes another function before setting the stack pointer. | 19:34 |
| poke53282 | Let's see if I can find a simple C example with this behavior. | 19:35 |
| poke53282 | arghh, no. Forgot the delayed slot of course. | 19:39 |
| poke53282 | The stack pointer is set. | 19:39 |
| mor1kx | [mor1kx] bandvig pushed 1 new commit to withfpu: https://github.com/openrisc/mor1kx/commit/5dd534d4b4e96ddcfde45dcf61971b37b417b251 | 20:02 |
| mor1kx | mor1kx/withfpu 5dd534d Andrey Bacherov: 1) re-factoring of division code to be closer to other (already re-factored) fpu modules... | 20:02 |
| --- Log closed Tue Nov 11 00:00:23 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!