IRC logs for #openrisc Wednesday, 2014-01-22

--- Log opened Wed Jan 22 00:00:04 2014
stekernthat tobil guy on the forums is starting to get me on my nerves...00:00
olofk_stekern: I think that's the guy who is making Arduinos with soft CPUs06:59
olofk__franck_: Hadn't thought of inline comments. That's a nice feature06:59
olofk_And where is the guy who asked for the JTAG adapter config?07:00
olofk_blueCmd: What do you want libffi for? Are you porting python to or1k or something? :)07:02
stekernolofk_: I can't find anything except some twitter tweets when googling arduissimo07:23
olofk_stekern: I think this is his stuff
olofk_Interesting. Hadn't seen this before07:25
olofk_aha.. gets even more interesting. It's the mysterious hyper pipeliner guy07:25
stekernnah, that tobias seems to have somewhat of a clue07:26
olofk_hmm.. you're right. Didn't think of that07:27
stekernbut actually, the username tobil is connected to that guy07:28
olofk_And arduissimo asked for some c++ stuff on twitter a while back. That's probably why I connected him to the guy on the forum07:30
olofk_Anyway, I'm curious to know if he has managed to compile the arduino stuff (prototype or processing or whatever it's called) for or1k07:32
olofk_He seems to reside in M√ľnchen so we should try to get him to the next orconf07:32
stekernI went by munich yesterday07:32
stekerndrank a beer there even07:32
stekernhe haven't even got the normal or1k toolchain working, so I doubt it...07:33
olofk_Nice. Still travelling around in Germany?07:35
stekernno, I'm back in Finland07:36
stekernI was only there for a one-day event in austria07:37
stekernand we thought s-macke's javascript emulator was off the charts, now this guy is writing the simulator for his cpu core in Excel!,Cores,0,525607:52
olofk_Oh yeah, that Hive thing is weird. Haven't got a clue if it's any good08:01
olofk_But anything that has a connection to Excel makes me very very scared08:01
olofk__franck_web_: Thanks.08:04
blueCmdolofk_: no, not yet :P09:29
blueCmdstekern: dpkg_1.17.5+nmu1_or1k.deb11:17
stekernblueCmd: excellent!11:17
blueCmd~ # LD_LIBRARY_PATH=/lib/or1k-linux-gnu/ dpkg --version11:23
blueCmdDebian `dpkg' package management program version 1.17.5 (or1k).11:23
xlrodid anybody here do successful synthesis with DC for the current mor1kx (cappuccino)? I get a weird error in the LSU about ctrl_rfb_i not being used in accordance with its stated direction, which I can't figure out. rewrote & refactored that part of the source (byte / half word padding) in couple different ways, almost always same error, or broken synthesis result11:30
stekernxlro: I don't have access to DC, so I haven't been able to try.11:32
stekernbut I'll hapilly try to help solving the problem11:32
xlrothanks, I looked already quite a bit at the source, and have no clue really how the signal could be used in the wrong way (e.g. driven by something, that's what the message suggested I assume)11:33
xlroI only get it for bits 0-711:33
xlroof ctrl_rfb_i11:34
stekernhmm, yeah, it's only used as a source in the mux to dbus_sdat11:34
xlrowhich then goes into the store buffer11:34
xlrowhen I remove the use of dat_i (just for testing) in the store_buffer I still get the same problem11:35
stekernso it seems like it's actually that mux that is the problem...11:37
stekernif it's not on the other side of the input the problem is11:38
xlroon the other side it comes directly from a register, so yes that's why I thought let's just rewrite it more clearly, e.g. case statement11:38
xlroalso I playe around a bit with intermediate temporary signals, and different ways to do that replication (e.g. {4{x}} etc), no help so far11:39
xlrosince it's such a trivial mux, I suspected there is something more fundamental that I missed and ask here :)11:39
stekernand if you assign dbus_sdat directly to ctrl_rfb_i it disappears?11:40
xlroif I assign ctrl_rfb_i (full 32 bit vector) directly to dbus_sdat I get no error11:41
xlrohere the full error message btw:
xlrosorry not ture11:45
stekernis it somehow the concentation of that signal from itself that it doesn't like11:46
xlroI mixed something up (with changing reg to wire), so if I just connect dbus_sdat with ctrl_rfb_i, I get the same erro, but for all 32 bits11:46
stekernok, so it's not related to the concentation or the mux11:46
xlrowhichso the mux and or concat seems not to be the issue11:46
xlrothat is also with the line assign fifo_din = 0; in the store_buffer, so dat_i is never used11:48
stekernoh, I think I've might have found something,    assign dc_sdat = dbus_sdat; should be moved inside the if (FEATURE_DATACACHE!="NONE") generate11:49
stekernbecause, since you have caches disabled (right?), dc_sdat get assigned in two places now11:50
xlroah yes exactly11:50
xlrothanks a lot that should be it11:51
xlrothe whole block must go in the if11:51
xlrocause all the signals get assigned twice as you say11:51
xlroyeah DC is sometimes not too good with the naming, its often all the same net ;)11:51
xlroactually thats the only one that is assigned twice, you were right, the others just look similar11:52
stekernyeah, I figured it had to be related to nets being squashed together11:52
stekernthanks for catching that bug ;)11:54
xlroalright cool, gate level simulation works11:56
xlroI somehow patched around it before, but after synthesis, all load store instructions basically failed ;)11:57
xlronow all looks perfect so far11:57
xlroiirc from orconf, you added the store buffer right?11:58
xlroit's a nice addition, but for the memory architecture we want to use (tightly coupled low latency data memory) I probably would need to remove it, what I saw from the source setting OPTION_STORE_BUFFER_DEPTH_WIDTH to 0 won't work, right?11:59
mor1kx[mor1kx] skristiansson pushed 1 new commit to master:
mor1kxmor1kx/master 1802f28 Stefan Kristiansson: cappuccino: lsu: move dc_sdat assign inside FEATURE_DATACACHE!="NONE"...11:59
stekernno, I don't think will work. Long term plan is to make setups with tcm configurable, since the current lsu and fetcher is highly unoptimized for that kind of memory architecture12:01
xlroindeed, currently I'm stuck at the 4 cycle per instruction, when I go over the bus, what do you think is the quickest way to get 1-cycle sram connected, just use the i and d cache interfaces bring them to the outside and just by default generate a hit?12:02
stekernyes, I would guess that would be the easiest way to achieve that12:03
xlrofor the store buffer currently I use depth 1, so 2 entries, but ultimately I want to save those 3x100 registers12:03
stekernI think the easiest way to completely disable it would be to replace the logic in there with comb bypass logic and always indicate that it's full12:06
stekern"in there" = inside the storebuffer module12:06
xlroI see, that makes sense12:06
stekernbut that's just from the top of my head, I might make some oversight here12:07
xlroI would still need one set of registers (100) I guess12:07
xlrobut at least removes the fifo12:07
stekernI was hoping you could avoid that with the comb bypass logic, but as I said, I might have forgot something12:08
xlrothe full always high probably won't work since you will never get rid of a pending write12:09
stekernok, yeah, that might be the case12:10
xlroI'll have a look at it, if I find a nice modular way to remove it I will try to make it a parameterizable (like the cahes & mmus)12:10
stekernbut one set of registers is perhaps not so bad, and IIRC it will break a critical path12:11
stekernif you do, please post patches! ;)12:11
xlrosure :)12:11
xlrobtw, is there an RTL diagram of some sort of the mor1kx capp pipeline somewhere? just out of curiosity, started drawing on A3 the other day.. ;)12:12
xlromaybe not with all the details obviously12:13
stekernoutside of my head, sorry, no12:13
xlroregarding the register file I have a question, are there architectural reasons that you double it in rfa and rfb, or is that mainly targeted to get two cheap read ports (especially on fpga where bram is mainly free)?12:15
stekernyou mean, why isn't it modeled as a true dual port ram?12:16
xlroyes, if you put it into a ram (many ways to build a rf as you probably know)- just in general the rfa and rfb always have the same content, right?12:17
xlroso it's not microarchitectural that you need two rfs, haven't looked too close at the architecture yet, so was just wondering12:18
stekernno, it's just to get a two read/one write port ram12:19
xlrook great12:19
stekernbut you could get that by model it as a two read/two write port "true-dual port ram" as well12:19
stekernor just implement the whole thing as one set of flip-flops12:20
xlroyes that's what I was thinking12:20
xlroyou would only need one write port currently, no?12:21
stekernbut with a "true-dualport" ram you'd get one extra write port (that you don't need)12:22
stekernin terms of what you usually get in FPGAs that is12:22
xlroah I see what you mean12:22
xlrothanks for your help, glad we already could squash a small bug! will look some more into the store buffer, how to bypass it, and will get back to you when I have that patch then12:26
stekernsounds great!12:28
olofk_lol. Drama on the OpenCores forum. What the hell is up with this guy?12:49
xlrothe last response was kinda funny, good troll ;)12:50
olofk_At least it's nice to see something other than people who want to get help with their homework12:51
_franck_web_I wouldn't have been so polite. stekern you are a gentlemen12:55
stekern_franck_web_: I know, it's my Achilles' heel12:57
olofk_hmm.. I found an old e-mail with an attached tar file that apparently contain an implementation of the performance counters for or120012:59
olofk_Does anyone know anything about that?12:59
olofk_What kind of performance does it count?13:00
_franck_web_isn't that described in the or1200 spec ?13:03
_franck_web_chapter 11.313:10
olofk__franck_web_: Looks like they could be useful. Guess I have to take a look at those patches at some point13:12
olofk_Not much activity on the OpenCores bugzilla16:08
stekerngood that you didn't sweep all away at christmas then16:14
_franck_after 4.5GB of download to get the brand new Quartus to be installed on my brand new Linux installation I get this:20:55
_franck_Your design targets the device family "Cyclone II". The specified family is ... not supported in this version of the Quartus II software20:55
_franck_damned !20:55
_franck_let's download 4.5GB again for an older version20:55
stekernheh, I got a new laptop at work, when copying the hd of the old one over to the new, I noticed that the three quartus version I had installed takes 35GB20:58
rokkastekern: btw. where do you work21:29
blueCmdrokka: you know willy wonka?21:39
stekernhaha, blueCmd you're observant ;)21:48
rokkawtf.. :D21:48
rokkablueCmd: yeees? :D21:48
_franck_I didn't know willy wonka but now I know why you said this blueCmd ;)21:49
stekernrokka: I work at an embedded consultant firm called Espotel, located in Finland21:49
rokkaok :)21:50
stekern if you want to know more ;)21:51
rokkaseems nice company21:53
stekernrokka: to explain blueCmd's comment, I have dubbed my computers with character names from "Willy Wonka and the chocolate factory"21:54
stekernand I own the domain (chokladfabriken = the chocolate factory in swedish)21:55
rokkaok. i am from finland21:56
stekernwhere about in finland?21:56
stekernok, I'm in Espoo, migrated to here from Sweden about 10 years ago21:59
rokkamight be usefull to know companies that do fpga/embedded stuff22:04
blueCmdstekern: look at that!23:13
* blueCmd is installing the first ever (I assume) OpenRISC Debian23:20
--- Log closed Thu Jan 23 00:00:06 2014

Generated by 2.15.2 by Marius Gedminas - find it at!