IRC logs for #openrisc Thursday, 2012-11-08

« Wednesday, 2012-11-07 Index Friday, 2012-11-09 »
@stekernwtf, I remove the slowest/most critical path that ISE found, then it comes up with an _even_ slower path...06:02
@stekernjuliusb: I'm starting to believe that your "early branch detection" actually could increase fmax on cappuccino09:12
@stekernsince it seems that most of our timing problems are related to detecting branches and calculating the branch target09:20
@stekernsplitting them up might make that net more lightweight09:20
@stekernand atm, if I have got this correctly, all branches are actually detected in execute stage09:21
@stekernfor cappuccino09:21
@stekernso, what branches was it that you "detect early" in prontoespresso?09:26
@stekernI guess I can't avoid waiting for execute stage to do register jumps09:27
@juliusbstekern: check out my mor1kx repo, the fetch_prontoespresso.v in there12:24
@juliusbI detect all, so I can halt the bus burst access, and all but the jumps using register addresses I calculate where we're jumping to and immediately put it out on the bus12:24
@juliusbthere's some optimisation to do in terms of removing the logic in the ctrl stage which looks at the jump target from the execute stage (so that stuff gets optimised away and we only have 1 set of decode logic, hopefully, for the jump/branch instructions, but that's for later)12:25
@stekernok, sounds good12:26
@juliusbI think also maybe syscalls, traps12:26
@juliusbi'm not sure how big the decode logic is tbh12:26
@stekernwhat I have in mind for cappuccino would be to move the branch calculation that is possible to decode stage, register it so it's available at the same time as it is now. And register the rest and take the 1 cycle latency for that12:28
@stekern(techically, the ones that get moved get 1 cycle latency too, but since we move them to an earlier stage, we should not see performace regression with that)12:29
@stekernof course, if it's no trouble to feed the output from the decode stage directly, we'll do that12:30
@stekernI think it's exception and addresses from registers that are causing most troubles12:31
@stekernwith some "proof-of-concept" hacks, I get the most critical path going from rf through dcache back to rf, which should be possible to handle with split up mem/wb stages12:32
@stekernand with some even more "proof-of-concept" hacks on that I get fmax to be 85 MHz for de0-nano and orpsoc12:33
@juliusbwhat do you mean by "register the rest"? do you mean register the l.j[al]r instructions in execute stage?12:36
@stekernno, just the branch_occur and branch_target12:37
@juliusbthe reason I was calculating the branch address in the execute stage was mainly to save logic by using the ALU's adder12:37
@juliusbahh right OK i'm with you12:37
@juliusbbut it's hard not to have a dedicated adder for branch targets12:38
@stekern(alu reuse) yeah, I know12:38
@juliusbas we've found out ;) plus you always take a latency hit on your jumps/branches so it's worth throwign some logic at making those operations as fast as possible12:38
@stekernI agree12:39
_franck_@VPI experts: http://pastie.org/534588816:14
_franck_how am I debugging this ?16:14
_franck_I tried to compile jtag_vpi.c with g flag then I got:16:15
_franck_http://pastie.org/534590216:15
_franck_it doesn't help that much...16:15
_franck_any idea ?16:16
@juliusb_franck_: wow, I'm not really sure to be honest17:03
@juliusbstack smashing haha17:03
_franck_it just crash at some point... :)17:03
@juliusbI'm not too sure of how different things are with -g and what might be doing some bad things to the stack17:06
@juliusbdid you do a complete clean and rebuild of everything?17:06
@juliusbperhaps changing one bit and not recompiling the whole thing is bad17:06
@juliusbi'd dlete everything and rebuilt17:06
@juliusbrebuild17:06
@juliusball VPI-related object files, all Icarus-generated things17:06
_franck_I'll try clean everything....17:07
_franck_so there is no way you'd know I could gdb the jtap_vpi.o ?17:07
_franck_the C part of the VPi object17:08
_franck_I'll debug with prints17:08
@juliusbOh I'm sure you could GDB to it somehow17:08
@juliusbjust run the vvp under gdb and then run it like you normally would and just set a breakpoint where you want it17:08
@juliusbI imagine that'd work OK?17:08
_franck_yeah I'll try17:09
@juliusbbut i'd clean everything17:09
@juliusbas Icarus is nice and open source you could even recompile that with all the debugging on :)17:10
_franck_that will be the next step if I can't find anything17:11
@juliusbbut debugging with printf() might be the quickest and easiest17:12
_franck_I can connect to the sim with openOCD, read JTAG id, dump resgisters17:14
@juliusbawesome17:14
_franck_now when I load I got this bug17:14
_franck_http://pastie.org/534615717:15
_franck_gdb talk a bit more17:15
_franck_I'll see what I can do17:15
@juliusboh, looks like a genuinue misuse of something in the VPI code17:17
@juliusbyou triggered an assertion in Icarus17:17
@juliusbsend_result_to_server (userdata=0x0) at jtag_vpi.c:24317:19
@juliusbwhatever you're passing there it doesn't like17:19
_franck_what is this pointer anyway ?17:20
_franck_userdata ?17:20
@juliusbsomething which is passed to that function of yours, send_result_to_server() isn't it?17:20
@juliusbI would have to see the code of that function17:20
_franck_is implicitly (? do we say that) used by vpi_scan or other vpi functions ?17:21
@juliusbhuh? I don't get you17:24
@juliusbyou're asking if this function is implicitly used?17:24
_franck_the userdata pointer17:24
@juliusbI have 0 idea, is this code you wrote or stuff already the VPI libs?17:24
_franck_http://pastie.org/534620617:24
@juliusboh yeah tha tlooks like code I wrote17:25
_franck_I took a lot from jp_vpi.c17:25
_franck_already in orpsoc17:25
@juliusbyep, umm, it's called in a system cal I think17:25
@juliusb$send_result_to_server()17:25
@juliusbin the verilog, I think17:25
_franck_ok, anyway, that's not the point...17:26
@juliusbwell that's where your crash is17:26
_franck_yes, I'll printf around to see what is going on17:27
@juliusbyou should check if argh is null or something17:27
@juliusband argval17:27
@juliusbi would double check if they're null17:27
_franck_yeah, I'll check everything17:28
@juliusbit looks like it expects a length integer, and array of data, if your verilog isn't using the function like that then it'll probably crash17:29
_franck_this function works at some point before the crash17:30
@juliusbhow and where are you using it?17:31
@juliusbthe $send_result_to_server() or whatever17:31
_franck_flip_tms = 0;17:32
_franck_do_scan_chain;17:32
_franck_$send_result_to_server(length, buffer_in);17:32
_franck_integer length;17:32
_franck_reg [31:0] buffer_in  [0:4095];17:32
@juliusbyou sure that's the only place?17:32
_franck_no, in two difference case(cmd)17:33
_franck_http://pastie.org/534626017:34
_franck_see17:34
_franck_`CMD_SCAN_CHAIN and `CMD_SCAN_CHAIN_FLIP_TMS17:34
@juliusbit looks like you've rmoved some checking I did, I had this same code in a couple of functions which double checked the type it got as vpiMemory (or, vpiRegArray as Modelsim liked to have it called)17:34
_franck_yes, it was a non need check in my case and I wanted to have less code lines ;)17:35
@juliusbhaha yep, but it may not catch the bug anyway, perhaps it's the first get-value thing17:36
@juliusbso, I don't know man, are you sure there's no other variables named integer?17:36
@juliusbI would gdb through it then and double check what gets passed in there17:36
@juliusband I would delete and rebuild everything17:36
_franck_yeah don't worry, I'll find, that the game we play :)17:36
@juliusbindeed17:37
@juliusb:)17:37
@juliusbremoving checking stuff from code like that is usually not a good idea, I probably did it for a reason ;)17:38
@juliusbi know it saves space, but it may not save you time in the end17:38
_franck_probably, I'll put it again, it was planed anyway for the release version17:39
@olofkthe userdata pointer is generally not needed17:43
@olofkMany of the examples include it, but you can remove it safely.17:43
@olofkIIRC, you can only assign that pointer when you register the systf. Might be wrong on that one, though17:45
@olofkOne fun part of VPI is that you can register syscalls during a simulation. I have absolutely no idea when that could be useful17:51
@juliusbhaha17:53
@juliusbomg17:53
@juliusbhave code on the simulated CPU write its own syscall\17:53
@olofk:)17:53
@juliusbthat's got to be a feature of skynet17:54
@juliusbhaha that would be awesome, seriously17:54
@olofkYeah, I was actually thinking of creating the world's first verilog virus17:54
@juliusbIt's C though, you'd kinda of need to write a lot of stuff in the VPI world to do it17:54
@olofkTo be more precise, it's shared objects, so I guess you could use whatever language you want as long as you provide the right hooks17:55
@juliusbhmmm17:55
@juliusbso some sort of C-Python thing17:55
@olofkI know that there is some python-based test environment that uses VPI17:56
@juliusband have the software on the processor emit Python strings which could then be evaluated in the Python via VPI17:56
@juliusbomg pretty sweet17:56
@olofkpython's exec function could work there17:56
@juliusbyep17:56
@juliusbbut then... the systemcall in the verilog would need to be precompiled?17:57
@olofkI'm going to implement callbacks in the orpsocv3 .core files using exec. Just hope that no one writes evil core descriptions :)17:57
@juliusb.core files?17:57
@juliusba thing for ORPSoCv3?17:57
@olofkyes17:57
@olofkWell, a bit off-topic, but I just discovered python's exec. Still happy about that :)17:58
@juliusbOh17:58
@juliusbno way?17:58
@olofkyes way17:59
@juliusbI love it, we embed all sorts of Python in our scripts around here and exec() away on the fly17:59
@olofkc00l. I would love to replace large parts of our scripting environment with something better (python-based)18:00
@olofkNever been a big tcl fan18:01
@olofkjuliusb: How do you run test cases for mor1kx? Is it the same elf to bin to vmem mechanism as in orpsocv2?18:29
@juliusbumm I think so18:53
@juliusbTCL is the worst thing ever18:53
@juliusbvs Python it's like chalk and cheese18:53
@olofkjeremybennett: I'm trying to break out cpu/parse.c from or1ksim, but it looks like a bit more work than I anticipated. Where is oraddr_t declared, for example?19:50
@olofkaha! in arch.h19:50
@olofkAre we using coff files anymore?20:05
_franck_juliusb: it was a stack smashing...20:32
_franck_an out of bound index in an array20:33
_franck_nothing to do with vpi_get_value(array_word, &argval) :)20:35
@olofkHey, can someone please ack my declare pcreg_boot before use patch? It's a bit problematic that or1200 is unusable at the moment20:36
@olofkin modelsim at least20:36
@juliusbolofk: silence = ack20:59
@juliusbbut, I'll pass an eye over it20:59
@juliusbyou're doing an assign though, I guess this is some v2k thing?21:00
@olofkyes. I think we are ready to use a feature that has been around for 11 years now ;)21:23
@stekernolofk: I reckon we should just post, commit, post a note it's commited on straight forward stuff like that21:38
@olofkYeah, I was on the verge of doing that. It was a trivial fix21:51
_franck_as I'm new to verilog and icarus, I wonder if someone can explain why i see this ?!23:54
_franck_http://picpaste.com/pics/franck-9jkS60mr.1352411631.png23:54
_franck_it is a basic for loog23:55
_franck_loop23:55
« Wednesday, 2012-11-07 Index Friday, 2012-11-09 »

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!