| --- Log opened Wed Jan 22 00:00:04 2014 | ||
| stekern | that 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 CPUs | 06:59 |
| olofk_ | Arduissimo | 06:59 |
| olofk_ | _franck_: Hadn't thought of inline comments. That's a nice feature | 06: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 |
| stekern | olofk_: I can't find anything except some twitter tweets when googling arduissimo | 07:23 |
| olofk_ | stekern: I think this is his stuff http://www.cloudx.cc/ | 07:24 |
| olofk_ | http://www.cloudx.cc/cloudx.32.or.html | 07:25 |
| olofk_ | Interesting. Hadn't seen this before | 07:25 |
| olofk_ | aha.. gets even more interesting. It's the mysterious hyper pipeliner guy | 07:25 |
| stekern | nah, that tobias seems to have somewhat of a clue | 07:26 |
| olofk_ | hmm.. you're right. Didn't think of that | 07:27 |
| stekern | but actually, the username tobil is connected to that guy | 07:28 |
| stekern | http://opencores.org/acc,view,tobil | 07: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 forum | 07: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 or1k | 07:32 |
| olofk_ | He seems to reside in München so we should try to get him to the next orconf | 07:32 |
| stekern | I went by munich yesterday | 07:32 |
| stekern | drank a beer there even | 07:32 |
| stekern | he haven't even got the normal or1k toolchain working, so I doubt it... | 07:33 |
| olofk_ | Nice. Still travelling around in Germany? | 07:35 |
| stekern | no, I'm back in Finland | 07:36 |
| stekern | I was only there for a one-day event in austria | 07:37 |
| stekern | and we thought s-macke's javascript emulator was off the charts, now this guy is writing the simulator for his cpu core in Excel! http://opencores.org/forum,Cores,0,5256 | 07:52 |
| olofk_ | Oh yeah, that Hive thing is weird. Haven't got a clue if it's any good | 08:01 |
| olofk_ | But anything that has a connection to Excel makes me very very scared | 08:01 |
| _franck_web_ | olofk_: http://opencores.org/forum,OpenRISC,0,5385 | 08:02 |
| olofk_ | _franck_web_: Thanks. | 08:04 |
| blueCmd | olofk_: no, not yet :P | 09:29 |
| blueCmd | stekern: dpkg_1.17.5+nmu1_or1k.deb | 11:17 |
| stekern | blueCmd: excellent! | 11:17 |
| blueCmd | yees | 11:18 |
| blueCmd | ~ # LD_LIBRARY_PATH=/lib/or1k-linux-gnu/ dpkg --version | 11:23 |
| blueCmd | Debian `dpkg' package management program version 1.17.5 (or1k). | 11:23 |
| xlro | did 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 result | 11:30 |
| stekern | xlro: I don't have access to DC, so I haven't been able to try. | 11:32 |
| stekern | but I'll hapilly try to help solving the problem | 11:32 |
| xlro | thanks, 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 |
| xlro | I only get it for bits 0-7 | 11:33 |
| xlro | of ctrl_rfb_i | 11:34 |
| stekern | hmm, yeah, it's only used as a source in the mux to dbus_sdat | 11:34 |
| xlro | exactly | 11:34 |
| xlro | which then goes into the store buffer | 11:34 |
| xlro | when I remove the use of dat_i (just for testing) in the store_buffer I still get the same problem | 11:35 |
| stekern | so it seems like it's actually that mux that is the problem... | 11:37 |
| stekern | if it's not on the other side of the input the problem is | 11:38 |
| xlro | on 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 statement | 11:38 |
| xlro | also I playe around a bit with intermediate temporary signals, and different ways to do that replication (e.g. {4{x}} etc), no help so far | 11:39 |
| stekern | odd | 11:39 |
| xlro | since it's such a trivial mux, I suspected there is something more fundamental that I missed and ask here :) | 11:39 |
| stekern | and if you assign dbus_sdat directly to ctrl_rfb_i it disappears? | 11:40 |
| xlro | if I assign ctrl_rfb_i (full 32 bit vector) directly to dbus_sdat I get no error | 11:41 |
| xlro | here the full error message btw: http://pastebin.com/0hQbvwdQ | 11:41 |
| xlro | sorry not ture | 11:45 |
| stekern | is it somehow the concentation of that signal from itself that it doesn't like | 11:46 |
| xlro | I 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 bits | 11:46 |
| stekern | ok, so it's not related to the concentation or the mux | 11:46 |
| xlro | whichso the mux and or concat seems not to be the issue | 11:46 |
| xlro | exactly | 11:46 |
| xlro | that is also with the line assign fifo_din = 0; in the store_buffer, so dat_i is never used | 11:48 |
| stekern | oh, I think I've might have found something, assign dc_sdat = dbus_sdat; should be moved inside the if (FEATURE_DATACACHE!="NONE") generate | 11:49 |
| stekern | because, since you have caches disabled (right?), dc_sdat get assigned in two places now | 11:50 |
| xlro | ah yes exactly | 11:50 |
| xlro | thanks a lot that should be it | 11:51 |
| xlro | the whole block must go in the if | 11:51 |
| xlro | cause all the signals get assigned twice as you say | 11:51 |
| xlro | yeah DC is sometimes not too good with the naming, its often all the same net ;) | 11:51 |
| xlro | actually thats the only one that is assigned twice, you were right, the others just look similar | 11:52 |
| stekern | yeah, I figured it had to be related to nets being squashed together | 11:52 |
| stekern | thanks for catching that bug ;) | 11:54 |
| xlro | alright cool, gate level simulation works | 11:56 |
| xlro | I somehow patched around it before, but after synthesis, all load store instructions basically failed ;) | 11:57 |
| xlro | now all looks perfect so far | 11:57 |
| xlro | iirc from orconf, you added the store buffer right? | 11:58 |
| stekern | yes | 11:58 |
| xlro | it'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: https://github.com/openrisc/mor1kx/commit/1802f28f43b7eb4fb85fdbab5f903102f9672ef2 | 11:59 |
| mor1kx | mor1kx/master 1802f28 Stefan Kristiansson: cappuccino: lsu: move dc_sdat assign inside FEATURE_DATACACHE!="NONE"... | 11:59 |
| stekern | no, 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 architecture | 12:01 |
| stekern | +that | 12:01 |
| xlro | indeed, 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 |
| stekern | yes, I would guess that would be the easiest way to achieve that | 12:03 |
| xlro | for the store buffer currently I use depth 1, so 2 entries, but ultimately I want to save those 3x100 registers | 12:03 |
| stekern | I 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 full | 12:06 |
| stekern | "in there" = inside the storebuffer module | 12:06 |
| xlro | I see, that makes sense | 12:06 |
| stekern | but that's just from the top of my head, I might make some oversight here | 12:07 |
| xlro | I would still need one set of registers (100) I guess | 12:07 |
| xlro | but at least removes the fifo | 12:07 |
| stekern | I was hoping you could avoid that with the comb bypass logic, but as I said, I might have forgot something | 12:08 |
| xlro | the full always high probably won't work since you will never get rid of a pending write | 12:09 |
| stekern | ok, yeah, that might be the case | 12:10 |
| xlro | I'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 |
| stekern | but one set of registers is perhaps not so bad, and IIRC it will break a critical path | 12:11 |
| stekern | if you do, please post patches! ;) | 12:11 |
| xlro | sure :) | 12:11 |
| xlro | btw, 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 |
| xlro | maybe not with all the details obviously | 12:13 |
| stekern | outside of my head, sorry, no | 12:13 |
| xlro | regarding 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 |
| stekern | you mean, why isn't it modeled as a true dual port ram? | 12:16 |
| xlro | yes, 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 |
| xlro | so it's not microarchitectural that you need two rfs, haven't looked too close at the architecture yet, so was just wondering | 12:18 |
| stekern | no, it's just to get a two read/one write port ram | 12:19 |
| xlro | ok great | 12:19 |
| stekern | but you could get that by model it as a two read/two write port "true-dual port ram" as well | 12:19 |
| stekern | or just implement the whole thing as one set of flip-flops | 12:20 |
| xlro | yes that's what I was thinking | 12:20 |
| xlro | you would only need one write port currently, no? | 12:21 |
| stekern | yes | 12:21 |
| xlro | k | 12:21 |
| stekern | but with a "true-dualport" ram you'd get one extra write port (that you don't need) | 12:22 |
| stekern | in terms of what you usually get in FPGAs that is | 12:22 |
| xlro | ah I see what you mean | 12:22 |
| xlro | thanks 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 then | 12:26 |
| stekern | sounds great! | 12:28 |
| olofk_ | lol. Drama on the OpenCores forum. What the hell is up with this guy? | 12:49 |
| xlro | the 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 homework | 12:51 |
| _franck_web_ | :) | 12:54 |
| _franck_web_ | I wouldn't have been so polite. stekern you are a gentlemen | 12:55 |
| stekern | _franck_web_: I know, it's my Achilles' heel | 12:57 |
| olofk_ | hmm.. I found an old e-mail with an attached tar file that apparently contain an implementation of the performance counters for or1200 | 12: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_ | olofk_: http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Fdocs%2Fopenrisc-arch-1.0-rev0.pdf | 13:10 |
| _franck_web_ | chapter 11.3 | 13:10 |
| olofk_ | _franck_web_: Looks like they could be useful. Guess I have to take a look at those patches at some point | 13:12 |
| olofk_ | Not much activity on the OpenCores bugzilla | 16:08 |
| stekern | good that you didn't sweep all away at christmas then | 16:14 |
| olofk_ | :) | 16: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 software | 20:55 |
| _franck_ | damned ! | 20:55 |
| _franck_ | let's download 4.5GB again for an older version | 20:55 |
| stekern | heh, 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 35GB | 20:58 |
| rokka | stekern: btw. where do you work | 21:29 |
| blueCmd | rokka: you know willy wonka? | 21:39 |
| stekern | haha, blueCmd you're observant ;) | 21:48 |
| rokka | wtf.. :D | 21:48 |
| rokka | blueCmd: yeees? :D | 21:48 |
| _franck_ | I didn't know willy wonka but now I know why you said this blueCmd ;) | 21:49 |
| stekern | rokka: I work at an embedded consultant firm called Espotel, located in Finland | 21:49 |
| rokka | ok :) | 21:50 |
| stekern | http://espotel.com/ if you want to know more ;) | 21:51 |
| rokka | seems nice company | 21:53 |
| stekern | rokka: to explain blueCmd's comment, I have dubbed my computers with character names from "Willy Wonka and the chocolate factory" | 21:54 |
| stekern | and I own the domain chokladfabriken.org (chokladfabriken = the chocolate factory in swedish) | 21:55 |
| rokka | :-D | 21:55 |
| rokka | ok. i am from finland | 21:56 |
| stekern | where about in finland? | 21:56 |
| rokka | tampere | 21:56 |
| stekern | ok, I'm in Espoo, migrated to here from Sweden about 10 years ago | 21:59 |
| rokka | :) | 22:00 |
| rokka | might be usefull to know companies that do fpga/embedded stuff | 22:04 |
| blueCmd | http://b8bc92a42d7282eb.paste.se/ | 23:13 |
| blueCmd | stekern: look at that! | 23:13 |
| * blueCmd is installing the first ever (I assume) OpenRISC Debian | 23:20 | |
| --- Log closed Thu Jan 23 00:00:06 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!