IRC logs for #openrisc Monday, 2014-11-10

--- Log opened Mon Nov 10 00:00:21 2014
olofkpoke53282: Haha. I have always wondered what that curved squre thing is on my keyboard :)09:13
-!- jeremy_bennett is now known as jeremybennett_09:19
olofkmaxpaln: I just took a look at your wb_bfm changes10:00
olofkI 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
olofkBut 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 data10:03
olofkSame with read10:03
olofkI 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_compare10:05
olofkSo writes would be 1. Fill write buffer in wb_bfm_master. 2. Call Write function10:06
maxpalnhi olofk: sounds good10:26
maxpalnI had a few additional thoughts over the weekend.10:27
maxpalnI 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
maxpalnSecondly, I think the addition on the wait states could be better10:29
maxpalnthe 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
maxpalnI 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
olofkmaxpaln: The original read_burst takes a flattened data array as one of its inputs10:41
olofksorry, write_burst10:41
olofkand read_burst outputs a flattened array10:41
maxpalnoh, I see - so the idea would be to maintain the old and new versions of these functions10:47
maxpalnwhat 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
Heshamwallento: A quick question, does optimsoc uses or1k as processor tiles?10:52
Igor_UniboHey there. This is Igor Loi from Univ of Bologna.10:58
Igor_UniboI have some questions about Espresso ProntoEspresso and cappuccino version of the core10:59
olofkIgor_Unibo: Hi. Ask away11:00
Igor_UniboI am working with davide rossi and Antonio Pullini (the guys that ere at the openrisc conference)11:01
Igor_UniboI a running some synthesis to compare our version with the cappuccino , espresso and prontoespresso11:01
Igor_Uniboand i was also running some test11:01
Igor_UniboIn the espresso and prontoespresso i have some issues11:01
olofkIgor_Unibo: The *espresso cores haven't been updated much lately, so they are likely to contain bugs unfortunately11:02
olofkjuliusb and stekern knows most about this though11:02
Igor_Unibook, cappuccino seems fine11:03
Igor_Uniboi mean it pass the test i made11:03
Igor_UniboBut 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_UniboIt uses 8 slot, 100Flip flop each, and i am wondering why this fifo is there and if can be removed11:04
olofkmaxpaln: 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_burst11:05
olofkIgor_Unibo: Yes, you can remove the store buffer by setting the parameter FEATURE_STORE_BUFFER to "NONE"11:06
olofkmaxpaln: So wb_bfm_transactor will be responsible for setting the data to $random before calling write_burst11:07
Igor_UniboOk this make sense now11:07
olofkmaxpaln: And other users of wb_bfm_master can set it to whatever they want11:08
Igor_UniboThanks for the clear explanation11:09
olofkIgor_Unibo: No problems. Happy to help11:09
stekernIgor_Unibo: the storebuffer is there to avoid the pipeline to stall on stores11:13
Igor_UniboHello 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 features11:15
stekernright, and I believe in the use case for or10n, you have tightly coupled memories, so stores should be fairly quick anyway11:17
Igor_Uniboyep exactly11:17
Igor_Unibowe have atomic accesses (single read or single write), and the actual protocol introduces some bubbles, because the data_ack_i is sampled11:19
stekernI 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 performance11:19
Igor_Uniboi am looking how to have 1 store or 1 read  per cycle11:19
Igor_UniboYes i saw it11:19
stekernit could be possible to exchange the caches with memories that always signal a hit11:21
stekernat least for a instruction ROM that'd work straight out of the box11:22
Igor_Unibowell the main difference is that our data memory is shared11:24
Igor_Uniboso we must arbitrate each request11:24
Igor_Uniboinstr cache is fine11:24
stekernIgor_Unibo: btw, if you have some testcase that breaks *espresso, feel free to share and I can take a look at it11:28
Igor_Unibowell the issue in espresso and pronto_espresso  is during the boot11:29
Igor_Unibomaybe is a stupid mistake i made11:29
Igor_Uniboanyway when i enter in the _start section, during the BSS clearing11:29
Igor_Unibo        /* Cache initialisation */11:29
Igor_Unibo        l.jal _cache_init11:29
Igor_Unibo        l.nop11:29
Igor_Unibo        l.jal flagsInit11:29
Igor_Unibo        l.nop11: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        l.sw    (0)(r5), r011:29
Igor_Unibo        l.sfltu r5, r611:29
Igor_Unibothe branch loops forever, never exits11:30
Igor_Unibothe last instruction is never executed11:31
Igor_Uniboso the core clears only the first lcation of the BSS11:31
stekernI think there are a couple of instructions missing in what you pasted11:32 or something is usually more suitable for pasting when the code is more than 1-3 lines11:33
Igor_Unibosorry i didn't know11:35
Igor_Unibosorry i have been disconnected11:36
Igor_Uniboi am not familiar with IRC11:37
Igor_Unibosorry for that11:37
stekernno worries11:37
Igor_Unibothe link is this one11:37
Igor_Uniboin cappuccino line 15 is executed in the delay slot i guess11:38
maxpalnolofk: 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
stekernpronto_espresso doesn't have a delay slot, so for that, you'd have to swap line 14 and 1511:38
stekernbut if you see the same problem in espresso, then that's weird11:38
Igor_Unibolet me try again and then i came back to you11:39
olofkmaxpaln: 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
maxpalnAh, I forgot that Verilog allows accessing of signals across the hierarchy.11:46
maxpalna handy thing for test fixtures! :-)11:47
maxpalnok, 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
olofkmaxpaln: Yes, and then we can remove the 1d data array argument from the original write_burst function12:16
olofkOr perhaps keep it for backwards compatibility and give the data-less function a new name12:16
olofkNahh.. we don't need backwards compatibility.12:17
stekernyeah, how'd we know about our users if we don't give anything to complain about ;)12:19
olofkActually, I can't find any users of the write_burst function outside of wb_bfm12:28
olofkstekern, _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
stekernit's not much more work than any other peripheral with a wb master12:37
stekernyou want a dedicated interface to the MC for it though, since it's bw hungry12:38
olofkGot it12:38
poke53282olofk: Yes, you can finally create filenames with this sign in jor1k. A missing features everyone is waiting since a long time. ;)17:03
poke53282The original reason is, that my filesystem will be used in to run big distributions like Archlinux. So we supported each other to fix bugs and to add missing features in the filesystem.17:06
olofkpoke53282: cool. Good that you can share code like that17:12
olofkAnd that missing sign was the only thing that held me back from using jor1k as main main computer17:13
poke53282olofk: 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
poke53282Yes, this sign stekern. Later when I zoomed in I saw, that it is a circle.17:22
poke53282I 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
poke53282Ahh, 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
olofkysionneau, 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
ysionneauplease poste your python file and error :)17:39
ysionneauyou just forgot print()17:40
olofkThere's something else17:40
olofkI just picked a random platform btw17:41
ysionneaumixxeo and m1 should work for S6DDRPHY17:41
ysionneaueven if on those board it's DDR and not DDR2 that should print you verilog17:41
olofkYeah, I was hoping for that17:42
olofkCan you try it on your installation?17:43
ysionneauI've got the same issue17:45
olofkI got it now17:45
olofkdqs_ddr_alignment must be a string or int17:46
olofkIt gets translated to a parameter17:46
stekernwhat did you use, an imaginary number?17:46
ysionneauNone <-17:47
olofkI used ¤ of course17:47
ysionneauolofk: I'm using "C1" in my simulation of S6DDRPHY17:47
olofkAll my variables are called ¤1, ¤2, ¤3 etc17:47
stekernah, didn't think about that17:47
ysionneauas a value for dqs_ddr_alignment17:47
olofkysionneau: Yeah, I suspect it some tech-specific parameter for the SERDES or DDR FFs17:48
ysionneauyou can put "C0" or "C1" or "NONE" but here anyway since you don't simulate you can put whatever string you want :p17:49
olofkJesus. Looking at the verilog code was a very bad idea :)17:51
ysionneauenjoy the OSERDES2 ISERDES2 ODDR2 and stuff17:52
olofkMmm... and that's only a small part of the 2795 lines17:53
ysionneauso many?17:53
ysionneaua "complete" design with a ddr controller + this PHY and wishbone stuff gives me 1387 lines total17:54
olofkYeah, I wonder if it included the MC as well17:54
ysionneauaccording to your python paste, only the PHY :o17:55
ysionneaushouldn't be that long17:55
olofkoh well. Got to run.17:57
ysionneausee ya!17:57
poke53282stekern: 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
poke53282Just a small example:
poke53282l.mul is executed first. What would happen if l.mul would be l.div and would raise a division by zero?18:47
stekernnothing, since we have the red zone18:47
stekernthat save of r1 is completely bogus btw18:48
poke53282Yes, there is a comment in the c compiler. They always force to save r1 because of a unwinding problem I think.18:49
stekernyes, it's a workaround for some dwarf thing18:49
poke53282I would like to investigate this if I would have a second live :)18:49
stekernthey = blueCmd ;)18:49
* blueCmd twitches18:50
blueCmdyeah something like that18:50
poke53282But what about try catch blocks and longjumps?18:52
poke53282They are all save with such a behavior?18:53
stekernlongjumps has it own context save, so that should be safe I think18:59
stekernto be honest, I'm not sure how dwarf exception handling works19:01
poke53282This one seems to be responsible flag.19:10
poke53282I don't know either stekern.19:10
olofkjeremybennett: Any news on the last GCC contributor btw?19:11
poke53282Maybe I should run the testsuite removing this optimization. Just to be sure.19:15
poke53282Here another example:
poke53282He executes another function before setting the stack pointer.19:34
poke53282Let's see if I can find a simple C example with this behavior.19:35
poke53282arghh, no. Forgot the delayed slot of course.19:39
poke53282The stack pointer is set.19:39
mor1kx[mor1kx] bandvig pushed 1 new commit to withfpu:
mor1kxmor1kx/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 2.15.2 by Marius Gedminas - find it at!