IRC logs for #openrisc Monday, 2014-07-14

--- Log opened Mon Jul 14 00:00:18 2014
stekernblueCmd_: I've noticed that too, it's a regression, introduced by wallento's multiway cache stuff04:16
stekernhaven't got to look at it closer if it's really a circular path, verilator sometimes get confused and marks paths that really aren't circular04:18
stekernsometimes just changing a 'always @(*) sig1 = sig2;' to 'assign sig1 = sig2' can remove them04:19
stekernthe statements aren't that simple of course04:20
stekernthere are a couple of ternary muxes where a case-statement would be more readable in mor1kx just because of that04:21
stekernfor instance:
stekerndalias: I've implemented futex_atomic_* in Linux to be able to use robust_list, but I'm still having some problems with the pthread_robust test. The problem is that when the kernel starts to walk the list, it ends in a 0 pointer.05:04
stekernI'm probably misunderstanding something, but looking at the code that 'generates' the list:05:05
stekernisn't that expected to happen if m->m_next is zero?05:06
stekern(i.e. when self->robust_list.head is zero at line 39)05:07
stekernhmm, maybe I start to understand this now...05:56
jtdesousaDoes anybody know how can programs do printf in the verilog and verilator testbenches for the fusesoc mor1x-generic system?10:23
jtdesousaok I see orpsoc_top10:26
jtdesousa     #(.UART_SIM (1))10:26
jtdesousa   dut10:26
jtdesousawhat's the best way to make it scanf rather than just printf ?10:38
stekernjtdesousa: you can look how it used to work in the old sysc tb10:57
jtdesousaI have done that and it is working10:58
jtdesousain that way10:58
jtdesousaI was hoping there would be a way forward with the new testbenches10:59
olofkjtdesousa: The support for simulated UARTs are still a bit unfinished unfortunately11:24
blueCmd_that would be quite easy to build though12:47
blueCmd_I want that for my project so I can sit down and build that tonight I think12:47
olofkblueCmd_: Awesome13:18
olofkBonus points if you make a VPI wrapper for it as well so that we can reuse it in the event driven sims13:18
olofkKind of like what is done for the elf-loader13:20
blueCmd_olofk: I will if you can tell me what VPI is13:21
olofkIt's the foreign language interface for verilog13:23
olofkIt allows you to register new system commands13:23
olofkAnd implement them in a .so13:23
olofkI think that Mr Milkymist uses it to embed a whole python interpreter in some clever way that I haven't investigated further :)13:25
olofkIn the OpenRISC project we use it for the JTAG server and Elf loading13:27
blueCmd_oh. I think I used something like that in modelsim before, but specific for modelsim13:39
blueCmd_I hooked up python to it as well13:39
olofkblueCmd_: Did you forget to include wb_axi_slave in your pull request?14:33
blueCmd_olofk: no, it's not written yet14:48
olofkWell, the python code looks nice14:48
blueCmd_I have the skeletons for the cores but they will need a bunch of testing and stuff. I have a special repo for that (bluecmd/wb-axi)14:49
blueCmd_avalon should work though14:49
olofkIn that case, I think we should remove the axi stuff from VALID_BUS_TYPES for now14:51
olofkWe can keep the rest if you're somewhat confident that the converters will work out14:51
olofkI'm a bit worried about the full axi4 conversion14:52
olofkNot "It will never work"-worried, but more like "It will be very inefficient"-worried14:53
olofkBut please prove me wrong. It would be awesome to have that bridge :)14:53
olofkAnd wb_intercon_gen will need a serious refactoring soon14:54
olofkI'm getting more and more eager to implement arbitrary width conversions. I think it will do wonders for performance14:54
olofkThe whole thing should probably be reimplemented with some graph helper library14:55
olofkSo we can drop in blocks easier14:56
olofkLike resizers, bridges, watchdogs and things like that14:56
jeremy_bennettblueCmd_: Just seen your comments from yesterday. Well done tracking down authors. The challenge will be some of the older authors who have fallen out with OpenCores. So characterizing what individual contributions they have made will be really useufl.15:33
jeremy_bennettI'm slightly surprised Rich D'Addio doesn't appear in the list, since he was the GCC maintainer for quite a while.15:33
blueCmd_jeremy_bennett: as for their individual contributions I'm not sure that's possible15:47
blueCmd_jeremy_bennett: for stuff that's older than we have revision history logs for I grabed copyright information from headers, I don't know of any other way to identify persons before that15:50
blueCmd_olofk: sure, we can drop it from valid for now15:51
blueCmd_olofk: I'm curious though, why would full AXI4 be slow?18:20
olofkblueCmd_: Because axi4 has separate channels for the data going in each direction. It's basically four AXI4-Stream ports18:29
olofkSo you usually send a burst of requests and get a burst of acks back18:30
olofkFor wishbone, we need every transaction to be acked18:30
olofkbefore we can start a new one18:30
olofkwishbone b4 remedies this somewhat18:31
olofkSo it's not really that axi4 will be slow, but it will not reach it's full potential18:32
blueCmd_olofk: right, WB is half-duplex and AXI4 is full18:33
blueCmd_AXI4 also supports transactions and out-of-order things18:33
blueCmd_but I don't think either is used that much18:33
olofkYeah, I never seen out-of-order been used18:34
blueCmd_maybe I'm wrong - but in any case it doesn't matter much since the CPU can probably only execute one thing at a time and having a WB<->AXI interface just at the CPU level and using an AXI interconnect would solve that issue if you were worried about that18:34
olofkThen you only have to worry about the indefinite wishbone burst lengths18:35
olofkFor most masters it's probably ok though, since they only generate fixed-size bursts in practice18:35
olofkWishbone masters18:35
blueCmd_yeah, there ought to be some issues - but for a first version it doesn't really matter much18:35
olofkNo, I agree. We can worry about that later18:36
olofkBut it will be tricky to have a complete generic wb<->axi4 bridge18:36
blueCmd_ofc, it might not even be possible to be 100% compatible18:37
olofkNot without resorting to FIFOs or RAMs to hold the data until all properties are known18:38
blueCmd_olofk: DPI or VPI for my uart?18:38
olofkEnough about that now. Start implementing :)18:38
olofkDPI is nicer, but it's a system verilog thing, and all tools don't speak system verilog good enough yet18:39
blueCmd_right, DPI it is. verilator seems to work with it18:39
olofkI was going to say VPI :)18:39
blueCmd_I'll make it easy enought support both18:40
olofkBut if you do it like the elf-loader, you can implement all the business logic and just add thin wrappers for the different cases18:40
blueCmd_yeah, that's how I would do it anyway18:40
olofkWe're soon reaching the point where we don't have to worry about sv support, which will be awesome since we can then use modports, records, multi dimensional ports and other things that would take verilog from the stone age18:41
blueCmd_into the bronze age18:43
blueCmd_but yes, that's why I use systemverilog in mexiko18:43
blueCmd_multi-dimensional ports mostly18:43
blueCmd_ugha, vpi is ugly :P18:44
olofkYeah, that's probably the biggest annoyance, and the reason why I decided to autogenerate the wb_intercon top-level18:44
blueCmd_what simulators does not support dpi?18:44
olofkmodelsim doesn't suport sv18:44
olofkThe big brother, questa sim does, but that costs ~50% more than modelsim18:44
olofkAnd there's no free version that supports it at all18:45
blueCmd_hm it does appear to support it18:45
olofkIcarus and verilator have been working on sv for the last couple of years. Not sure how much of the standard they have implemented yet18:45
olofkQuartus and ISE supports part of the standard as well18:46
olofkhmm.. are you sure about that? Do you mean the free version?18:47
blueCmd_free version doesn't support anything18:47
blueCmd_but the non-questasim one18:47
blueCmd_this random blog:
olofkah ok. It will stilly require a separate add-on license18:48
blueCmd_and that is not the case for vpi?18:49
olofkNope. VPI is part of the verilog standard and is supported by all modelsim versions as well as icarus18:49
olofkverilator implements some parts of VPI as well, but I haven't tried that18:50
olofkHmm.. looks like I'm wrong here. Keep reading that modelsim supports the design features of system verilog, but not the verification features18:54
olofkSo all the things I mentioned previous might actually be supported18:54
blueCmd_i'd mucher implement it in DPI I think18:55
blueCmd_just looking at example code18:55
olofkYeah, it's a lot nicer18:55
olofkDo the DPI implementation first then, and try it with different simulators to see if it works18:55
olofkJust remembered that if you're using fusesoc, you will need to hack in DPI support. Only VPI is supported right now19:07
blueCmd_olofk: glad I'm not using fusesoc then ;)19:38
olofkhaha. Then you should be alright :)19:45
olofkblueCmd_: You could also push the uart data through a socket. That's also on my TODO list :)19:53
olofkSo you can telnet into the simulation19:54
olofkUseful if you're having the simulation on a different machine, or if you want to write debug info on stdout19:54
blueCmd_olofk: that's just piping to nc20:41
blueCmd_or no, not really20:42
blueCmd_hm, yeah - that's up for someone else. I just run it over ssh20:42
blueCmd_it supports different streams for in / out, it doesn't need to be stdin/stdout but writing reliable socket stuff is a pain20:42
olofkIs it really that hard? I've used it in some VPI code at work and _franck_ uses it for the JTAG server20:48
olofkI'm pretty green when it comes to sockets though, so most probably there are things I'm not seeing20:49
blueCmd_olofk: yes, it is hard. have you ever wondered why telnet prompts suck and ssh is much nicer?20:54
blueCmd_not to discuss ipv620:54
olofkYeah, telnet isn't all that nice, but you can use netcat instead20:55
blueCmd_still same20:55
olofkAnd I never thought it had anything to do with the underlying socket implementation20:55
blueCmd_i'm talking about real terminal control20:55
olofkAnd ssh must still use sockets, right?20:55
olofkAh ok20:55
olofkYes, I admit I ignored that part20:56
blueCmd_yes, ofc it uses sockets.20:56
blueCmd_that's socket boilerplate20:57
blueCmd_that's just for the setting up the socket20:57
blueCmd_never mind handling all the signals and special conditions you have20:57
olofkah cool. I've actually considered adding that kind of boilerplate to a vpi_socket core that can be used to implement pushing different protocols over sockets. It's on my TODO list :)20:58
olofkBut ok, I see that it can be a bit problematic to use for stdio, since we have to catch all escape sequences21:00
olofkFor well-behaved data it shouldn't be any problems though, right?21:00
blueCmd_data is never well-behaved21:02
blueCmd_you can do it for basic stuff yes, but it will suck for anything prompt-related21:03
olofkTime to wrap an SSH client into VPI then :)21:04
olofkOr use dbus :)21:04
olofkI could probably come up with even worse ideas if you give me some time :)21:04
blueCmd_IMHO, just dump the debug data to text files or whatever21:05
olofkWhat annoys me the most is that it would all be very simple if just verilog's getc wasn't line buffered21:06
blueCmd_which is exactly my point21:06
blueCmd_that is not verilogs fault21:06
blueCmd_you would have the same problems with using sockets21:06
blueCmd_because it's the terminals fault21:06
blueCmd_you have to t.c_lflag &= ~(ICANON | ECHO);21:07
blueCmd_to tell it to flush without newline21:07
blueCmd_I do stuff like that in my uart DPI module to make it nice and smooth21:07
olofkBut then it can't be the terminal's fault. It must be the $fgetc implementation in the various verilog sims that do it wrong21:07
olofkAnd/or the LRM that doesn't specify how it should be done, or provide alternative ways to do buffering21:08
blueCmd_if you do fgetc in C by default it will not catch single characters21:08
olofkis that getchar then?21:10
olofkI admit learning C from an early 80's edition of "Vägen till C", so my knowledge might be a bit outdated :)21:13
blueCmd_olofk: hah, yeah getchar isn't really a thing21:17
blueCmd_it sucks in that you don't know what you get21:18
blueCmd_if you turn on non-blocking mode (so that you can read every character without newline) it returns 0 - so if you want to read actual \00 you cannot21:18
olofkDoes the cryptic line you pasted above solve that?21:19
blueCmd_olofk: it makes it not block21:20
blueCmd_olofk: no matter what you try, every read call targeted at stdin will block until you hit return21:20
blueCmd_i.e. the key (a.ka. enter), not "return 0;"21:20
blueCmd_you _need_ to set stdin in non-blocking mode for that, as well as tell it to not wait for newline (which is the funky line)21:21
olofkOh well. Then the verilog $fgetc is probably the easiest way to do it anyway then?21:21
olofkah ok21:21
blueCmd_olofk: so what you _can_ do is that in your testbench.cpp or in your DPI module you run the things I do in uart_init21:22
blueCmd_you can potentially even make a program that does these things and then exec's the simulator so that the simulator gets the modified stdin21:23
blueCmd_jtdesousa: for UART in testbenches:
stekerninteresting, openrisc Linux doesn't complain about this:
blueCmd_olofk: I submitted a commit to my pull request for wb_intercon_gen to disable axi4 and axi4-lite for now21:39
blueCmd_you _just_ commented21:39
blueCmd_olofk: done21:44
blueCmd_stekern: if you could have a look at the Verilog part of that would be stellar21:45
blueCmd_since I'm changing your poor avalon bridges21:45
blueCmd_stekern: also, that's odd (the pastie)21:45
stekernyeah, I took a look earlier, I think it looks fine21:49
olofkblueCmd_: I'm not very hot on the submodules idea (surprise! :))21:49
blueCmd_stekern: i was prepared to fight you on 'master input' = 'slave'!21:49
blueCmd_olofk: yeah, lucky for you that I'm here to convince you!21:50
stekernit's changing the de-facto-standard avalon signal names, but I guess that's to fit better into wb_intercon?21:50
blueCmd_stekern: in wb_intercon every direction is either m2s or s2m, it kind of makes sense to keep it that way21:50
olofkI'm not very hot on changing de-facto standard names either (except for the stupid wishbone data from slave signal)21:51
blueCmd_stekern: ah for avalon21:51
blueCmd_stekern: so the signal names are generated "m/s_bus_port_dir" or something like that, so yes - that makes it fit nice and snug21:51
blueCmd_that said, it can be a format string per bus type as well21:52
blueCmd_so it's certainly not impossible21:52
stekernbut you're just changing the prefix, so I'm not going to make a big fuss about it if it makes life easier elsewhere21:52
blueCmd_right. it does make it easier (if not easier to read I think)21:53
olofkblueCmd_: The reasons I'm against the submodules are:21:53
olofkVery nice!21:53
olofkI would like to see the exceptions being caught in main, and not adding the new bus types to VALID_BUS_TYPES until we have implementations for the bridges. Other than that it looks good21:53
blueCmd_for axi there is yet another format so21:53
blueCmd_olofk: ! :D21:53
blueCmd_22:53 < olofk> blueCmd_: The reasons I'm against the submodules are:                                                   |21:53
blueCmd_22:53 < olofk> Very nice!21:53
blueCmd_you're really selling it21:54
olofk1) I don't want to tie this to a particular VCS without any great benefits21:54
stekernolofk: you're already screwed there, you're tied to svn21:54
olofk2) I want the repo to be read-only for use on shared systems21:54
blueCmd_(and github)21:54
olofk3) It might clash with the work I'm doing on versioning support21:54
blueCmd_2) git submodules update --recursive --remote should check everything out at once21:55
blueCmd_or something like that21:55
blueCmd_and submodules will not update themselves once they have been fetched once, as it is now21:55
blueCmd_3) how so?21:55
stekernit's actually not so odd that Linux doesn't complain about the 0 pointer derefencing I think, after all, we are running our code in that page21:55
olofk4) I want to move most of the actual code away from orpsoc-cores, and then it would be easy for anyone to set up their own meta repository with the cores they want anyway21:55
blueCmd_stekern: yes, but it shouldn't be mapped in userspace, right?21:56
stekernumm, how would you otherwise run the code?21:56
blueCmd_4) submodules makes that easier :P21:56
blueCmd_stekern: not from page 0? :P21:56
olofkblueCmd_: 4) Yes. But not with orpsoc-cores as the meta repo21:57
stekernblueCmd_: but the code is in page 021:57
blueCmd_olofk: why?21:57
blueCmd_stekern: why?21:57
olofkgod: why?21:57
stekernwell, that's perhaps a good question ;)21:57
blueCmd_olofk: I mean, how is it any harder / easier with/without submodules to set up a new meta repository?21:58
stekernbut it's not really Linux fault21:58
olofkblueCmd_: Well, for fusesoc users, we're not gaining anything by changing to submodules21:59
blueCmd_yes we are21:59
blueCmd_we gain support for repositories not on git21:59
blueCmd_github provider doesn't play well with repositories outside of github21:59
stekerns/not on git/not on github22:00
olofkNo, that's true. Especially since I replaced the code to get an archive instead of cloning22:00
olofkBut I always intended to add a generic git provider whenever that was needed22:00
HeshamHi all, I have a problem regarding gdb, any help?22:00
blueCmd_hi Hesham !22:00
Heshamhi Christian22:01
blueCmd_must be in the middle of the night where you are22:01
HeshamYeah, it's :)22:01
blueCmd_what's up with gdb?22:01
blueCmd_(we're having multiple conversations here, so try not to be confused! :) )22:01
HeshamFirst I am writing as assembly function let's call it _OR1K_Exception_Process22:01
blueCmd_olofk: honestly, with submodules you're better than opencores for a central core repository22:02
HeshamI am calling this function from the exception entry using l.jal register from another assembly file22:02
HeshamThe _OR1K_Exception_Process allocate space of 128 byte for registers to be saved on stack22:03
HeshamThe problem is when I try to set a break point at _OR1K_Exception_Process from gdb22:03
HeshamI got gdb internal error22:03
Hesham../../gdb-7.7/gdb/or1k-tdep.c:1016: internal-error: or1k_skip_prologue: Assertion `or1k_analyse_l_addi (inst, &rd, &ra, &simm) && (OR1K_FP_REGNUM == rd) && (OR1K_SP_REGNUM == ra) && (simm == frame_size)' failed.22:03
HeshamThis piece of code is the problem I think "(simm == frame_size)"22:04
HeshamIs there something wrong I may have in my code that causes this error ?22:04
blueCmd_does this only occur for exceptions?22:04
olofkblueCmd_: I have to think a bit about it, but I'm still not convinced22:05
HeshamIt only happens with this function22:05
HeshamI used to set a break point at _timer: (0x500)22:05
Heshamand it works fine22:05
blueCmd_olofk: well, you keep talking about being decoupled and not depending on stuff22:05
blueCmd_olofk: if you reject this idea you're being a hypocrit, the repository is a git repository and not using its features is not being decoupled22:06
stekernI would guess that it's the stack manipulation that throws it off22:07
Heshamstekern: I think so, but why?22:07
blueCmd_what stekern said, have you tried with "our" newlib to see if you can register a function for exception entry and break on it?22:07
blueCmd_if that works you can work from the differences on the stack I guess22:08
HeshamBut why or1k_skip_prologue assert of frame size ?22:09
blueCmd_as stekern said, if gdb tries to reconstruct the frame and call stack and the registers are messed up - it will fail22:10
stekerncan you show your _OR1K_Exception_Process?22:11
olofkblueCmd_: It would still work without the changes to the .core files, right?22:11
blueCmd_olofk: that is correct22:11
Heshamstekern: Sure, one second ..22:12
olofkI say we start with that. I really need to write down the ideas for versioning support before I change the provider stuff22:12
blueCmd_olofk: it's also possible to infer the github provider information from the .gitsubmodules file22:12
blueCmd_sorry, .gitmodules *22:12
blueCmd_olofk: what is better than to do versioning with git revisions?22:13
olofkblueCmd_: human readable version tags so that you know which versions that comes after another22:14
blueCmd_olofk: sure, but that needs to map to a revision some way or another22:14
olofkLike you have in all package formats. Package A depends on package B>=version22:14
olofkYes. With tags22:15
blueCmd_I'm just saying that instead of downloading a tar archive from github you can just pull the git repository and check out that version22:15
olofkfusesoc used to do that22:15
blueCmd_What changed?22:15
olofkI changed it to get an archive to avoid a hard dependency on git22:15
Heshamstekern: Here it's
HeshamAnd that's the file from which this function is called
blueCmd_olofk: how would it have been a hard dependency?22:17
Heshamline 1422:17
blueCmd_have had been*22:18
olofkblueCmd_: You would have needed git to get the repos on github.22:18
blueCmd_olofk: just like you need svn to get svn22:18
olofkVery true, but I couldn't avoid that22:18
blueCmd_just like you need git to get fusesoc22:18
olofkblueCmd_: No, there are versioned tar balls on the opencores ftp22:18
blueCmd_(well I guess you can tarball it as well)22:18
stekernHesham: ok, so gdb thinks that that looks like a function prologue that gcc would emit22:19
blueCmd_I'm just saying that avoiding git is a mistake. Hardware community needs more inovation, not less22:19
olofkI don't think it's any point to actually avoid depending on git, but I saw that I could get around it back then, so I did it22:19
stekernyou can workaround it by moving the 'l.sw  8(r1),r2' after 'l.sw  20(r1),r5'22:20
stekern(or we should just remove that assert)22:20
Heshamstekern: yes, I also deleted @type function and have the same problem22:20
blueCmd_olofk: I totally understand that, but to change from depending on git to only allowing github repos, is it worth it?22:20
stekernolofk: rather ditch the svn dependency and only depend on git then...22:20
blueCmd_stekern: +122:20
olofkblueCmd_: No, but since I started the project, there hasn't been a single core outside of opencores SVN or github that has been of interest, so I never wrote the generic git provider22:21
blueCmd_olofk: I know that _franck_ has some stuff on assembla22:21
olofkstekern: Yeah, considering the recent opencores instability I think we should clone the interesting repos to github22:21
olofkAnd of course, I'm more inclined to have a hard dep on git than on svn22:22
stekernyou can also use git as a svn client22:22
olofkstekern: Depends on which use flags you have provided when you compiled git :)22:22
olofkInstalled versions: 2014-06-19)(blksha1 curl gnome-keyring gpg iconv threads webdav -cgi -cvs -doc -emacs -gtk -highlight -mediawiki -nls -pcre -perl -ppcsha1 -python -subversion -test -tk -xinetd22:23
Heshamstekern: Great, that works!22:23
stekernfair enough, you can always fall back to a 'pure' svn client if some poor sole needs that then ;)22:23
HeshamThanks stekern and blueCmd_22:24
blueCmd_Hesham: np, I did a lot of helping! ;-) take care :-)22:25
olofkanyway. My arguments still stand that I need to figure out how this will work with the upcoming versioning support, and I would prefer orpsoc-cores to be put in a read-only location22:25
blueCmd_olofk: tbh, it should be the other way around :P22:25
HeshamAh, blueCmd_ you should, you are my mentor ;) :D22:25
blueCmd_olofk: i.e, make it nice then add versioning - and this will help you22:26
HeshamblueCmd_: BTW, Joel asked me to keep up with you about the binutils patch, would you submit it, or should I ?22:26
olofkblueCmd_: I don't see it that way22:26
blueCmd_Hesham: I can merge it if you feel like it's done.22:26
HeshamI believe it's now after your comments22:27
olofkBut I don't mind adding the .gitmodules file22:27
blueCmd_olofk: fair enough, if you feel like brainstorming how versioning will work I can try to convince you how git will Solve Everything (TM) there as well22:27
blueCmd_olofk: do you mind adding the _support_ for submodules in fusesoc?22:27
blueCmd_i.e. my fusesoc pull request22:28
olofkblueCmd_: Ah yes. I like the idea. Just haven't looked at the code yet22:29
blueCmd_olofk: I can accept your compromise until you're back from your versioning hippie vision quest22:29
olofkI'll take a closer look tomorrow. Got to sleep now22:33
blueCmd_olofk: good night :)22:35
--- Log closed Tue Jul 15 00:00:20 2014

Generated by 2.15.2 by Marius Gedminas - find it at!