| --- Log opened Fri Sep 13 00:00:54 2013 | ||
| poke53282 | stekern: Patch send to mailing list. Finally the varargs problem is at least documented. | 00:29 |
|---|---|---|
| stekern | poke53282: excellent! I was going to ask you about it since I want to use that as a base for discussion about a v2 API during orconf | 03:09 |
| poke53282 | Nice, are there other parts of the ABI that needs revision? | 03:25 |
| stekern | let's say it this way, if we would go down the path and create a v2 ABI, there are other things that would be nice to change while we are at it | 03:28 |
| stekern | call-saved, callee-saved register order is one | 03:28 |
| poke53282 | Of course, would be a bad idea to do gradual change of the ABI. People will get crazy. | 03:29 |
| stekern | exactly, so we need to have a good plan of what should go into v2 before we start hacking on it | 03:31 |
| poke53282 | Then keep in mind a small detail which I have written in the email. I made two changes, The second one is the splitting of the arguments. This is not necessary but simplifies the implementation of the new varargs handling in gcc significantly. | 03:54 |
| stekern | poke53282: ok, thanks for the heads-up of that | 04:51 |
| stekern | I will probably take that patch and apply it to a seperate tree so it doesn't get lost too | 04:55 |
| stekern | and we need to sync against upstream to get the native gcc bugfix and the tex fix too | 04:56 |
| stekern | I'll try to switch into toolchain mode next week sometime, right now I have too much fun playing with the sockit board ;) | 04:57 |
| stekern | I can read and write the DDR3 connected to the ARM from the openrisc side now | 04:57 |
| stekern | but it's odd, all addresses are shifted by 4 bytes compared to what the ARM sees | 04:58 |
| stekern | ah, no, it looks like the first access always returns garbage and the rest is shifted | 05:25 |
| stekern | so I probably latch the data at the wrong clock edge | 05:26 |
| stekern | now it works | 05:50 |
| poke53282 | I like your toolchain mode more than your FPGA mode ;) | 06:01 |
| stekern | haha | 06:02 |
| stekern | weren't you in progress of purchasing an FPGA board though? | 06:02 |
| stekern | maybe you will appreciate the FPGA mode more after that ;) | 06:03 |
| poke53282 | But of course I am also curious about the FPGA progress. Wondering what is the problem about the DDR3 access. Do you have to follow the DDR3 hardware access protocol? | 06:04 |
| poke53282 | Yeah, probably. I have not ordered yet. Shame on me. | 06:04 |
| stekern | no, this particular DDR3 access is dead simple, the hps (hard processor system) have an AXI port available for the FPGA fabric to use | 06:05 |
| stekern | ...and then that is translated to an avalon bus by the altera tools | 06:06 |
| stekern | and avalon is very easy to access from the wishbone bus (the bus protocol we use) | 06:07 |
| stekern | the only thing that differs are really how burst accesses, but if you don't support that it's just a matter of hooking up signals | 06:07 |
| stekern | *how burst accesses are handled | 06:08 |
| stekern | now, on this sockit board, there are two DDR3 memories, one that is intenden to be used by the HPS (the one that I hook into now) and another that is intended to be used by the FPGA | 06:08 |
| stekern | the second DDR3 will need more work to get access to | 06:09 |
| stekern | so, I basically (will) have 2GB of DDR3 accessible by the openrisc core | 06:10 |
| poke53282 | nice, hopefully it will be fast too. | 06:14 |
| poke53282 | So, I have to jump into my bed. | 06:14 |
| stekern | nighty night | 06:15 |
| poke53282 | Thanks | 06:16 |
| olofk | stekern: Good work. My sockkit is in a packed in a box now unfortunately. | 07:09 |
| stekern | keeping it in mint condition! ;) | 07:19 |
| _franck_ | I really need to push my de1 port so I'm done with it and I'll move to the sockit | 07:21 |
| stekern | the rise of the sockittens! | 07:24 |
| olofk | Go Sockittens! Go! | 07:25 |
| stekern | olofk: wb_intercon_gen feature request, break lines at 80: https://github.com/skristiansson/orpsoc-cores/commit/5042c5709500f8819e8dc1120376a3ae892b0f00#L1R273 | 07:26 |
| stekern | perhaps it's easier to just split it so that each signal is on its on line | 07:28 |
| stekern | olofk: what kit for your socks are you speaking about btw? | 07:30 |
| olofk | :) | 07:30 |
| stekern | needle and thread? | 07:31 |
| _franck_ | https://www.google.fr/search?q=socks+kit&tbm=isch&tbo=u&source=univ&sa=X&ei=M78yUoqICOfA0QX29YHABg&ved=0CC8QsAQ&biw=1920&bih=1075&dpr=1 | 07:31 |
| olofk | I think we need a sock building workshop at orconf | 07:32 |
| stekern | http://www.sockitgel.com/Home.html | 07:32 |
| _franck_ | :) | 07:32 |
| olofk | stekern: Yeah, that's the one I have. I still don't understand how you managed to squeeze in an OpenRISC in the tube | 07:32 |
| olofk | stekern: Yeah, I guess that the lines can become quite long. I'll fix that | 07:33 |
| stekern | olofk: thanks, I'd do it my self, but I figured it's such an easy thing to fix that it'd easier for both you and me if I just tell you about it | 07:35 |
| stekern | next step for sockit is to get the FPGA DDR going | 07:47 |
| olofk | Please don't talk about DDR right now | 07:49 |
| olofk | I've been spending the last month hunting down a bug in a generated DDR2 controller | 07:49 |
| olofk | I've been tempted more than once to just rewrite the fucking controller myself | 07:52 |
| olofk | or is it hard DDR3 controllers in the SoC Cyclone? | 07:52 |
| stekern | the one connected to hps is hard at least, I'm in the progress of investigating if there is a hard one for the one for the FPGA side too | 07:57 |
| olofk | Is there a git cat that I can use to look at a file at a certain revision? | 08:11 |
| olofk | or git diff between a VCS-controlled file and another file | 08:13 |
| stekern | git show | 08:21 |
| olofk | aha | 08:23 |
| stekern | no, that's not what you asked for | 08:25 |
| stekern | actually, it can do | 08:28 |
| stekern | I didn't know it could though | 08:28 |
| olofk | Anyone has recommendations for a text based diff tool? I use meld usually, but I don't have X forwarding now | 08:29 |
| stekern | git show <commit>:<file> | 08:29 |
| olofk | Thanks. That's good to know | 08:29 |
| stekern | I usually just use plain diff when in text mode | 08:29 |
| stekern | and diffmerge in X | 08:30 |
| stekern | vimdiff is pretty godd I think, I've only briefly tested it though | 08:31 |
| stekern | *good | 08:32 |
| olofk | vimdiff as in crazy-ass-vi-commands-diff? | 08:33 |
| _franck_ | just use meld | 08:34 |
| olofk | _franck_: Don't have any display :( | 08:35 |
| _franck_ | ah ok sorry | 08:36 |
| olofk | But I found a way. Running a shell in a split buffer in emacs where I can have the diff output | 08:37 |
| stekern | has meld became better, last I tried it it wasn't good enough | 08:38 |
| olofk | I think it does a good job | 08:38 |
| stekern | I'd like to switch to that from the closed source diffmerge, but it just didn't cut it | 08:39 |
| stekern | can you turn off that crazy mode where it shows the diffs like this? http://www.le-libriste.fr/wp-content/uploads/2009/06/meld.png | 08:40 |
| olofk | What's the problem? | 08:40 |
| _franck_ | this mode is great ! | 08:41 |
| stekern | the code that isn't changed isn't lined up together! | 08:41 |
| olofk | If you scroll it will align | 08:41 |
| stekern | this is how it should look like: http://oompa.chokladfabriken.org/tmp/diffmerge.png | 08:45 |
| stekern | can you edit in the window on the right? | 08:46 |
| stekern | I mean, manually | 08:47 |
| olofk | yep | 08:47 |
| stekern | I think it couldn't before (or then that was kdiff3) | 08:47 |
| stekern | three-way merges? | 08:48 |
| _franck_ | yes | 08:48 |
| stekern | directory diffs? | 08:48 |
| _franck_ | (three way) at least when I use it with git | 08:49 |
| _franck_ | directories, yes | 08:49 |
| stekern | maybe it was just the ugly diffs that put me off with meld | 08:49 |
| olofk | It handles git and svn too, but not clearcase | 09:02 |
| olofk | stekern: I looked a bit closer at your intercon changes now, and I'm not sure it's a good idea to drop the _i/_o indexes on the top level ports | 09:48 |
| olofk | I vote for dropping the m2s suffixes on the interface and bring back _i/o instead | 09:49 |
| _franck_ | I would also vote for this. For me, when we were talking about this notation, I was thinking about this: | 09:53 |
| _franck_ | https://github.com/fjullien/orpsoc-cores/blob/master/systems/de1/rtl/verilog/orpsoc_top.v#L237 | 09:53 |
| _franck_ | add it only on the data wire signals | 09:53 |
| olofk | I think it can be good to have it on all signals so it looks more symmetrical | 09:54 |
| olofk | But the names you have for the interface ports is the same that I would like to have | 09:55 |
| olofk | otoh, you can name the signals in your orpsoc_top to whatever you want | 10:00 |
| olofk | This has turned out to be an excellent bike shedding discussion :) | 10:01 |
| stekern | olofk: I think I agree on removing m2s on wb_intercon interface and bring back _i/_o | 11:44 |
| stekern | I did that because it makes AUTOINST work | 11:45 |
| stekern | but if you provide an instantiation with the generation that becomes moot | 11:46 |
| _franck_ | olofk: have you tried using orpsoc behind a proxy ? | 11:59 |
| _franck_ | setting http_proxy in my environment should be enough but it does not work | 12:00 |
| _franck_ | it can't download github archive. However, wget the same link works | 12:03 |
| _franck_ | no wget does not work, need to find why | 12:07 |
| _franck_ | export http*s*_proxy=http://.... was the solution | 12:13 |
| olofk | _franck_: There is support for setting proxy in the python functions. That might go in orpsoc.conf | 12:15 |
| olofk | _franck_: Does orpsoc work when you export the proxy stuff too? | 12:18 |
| _franck_ | yes | 12:18 |
| _franck_ | have had http_proxy exported. I needed to export https_proxy | 12:19 |
| _franck_ | s/have/I | 12:19 |
| olofk | Great. Then we don't need to fix orpsoc | 12:25 |
| stekern | according to this, there should be 2 hard memory controllers: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=816&PartNo=2 | 13:16 |
| _franck_ | stekern: I'm sure you'll find what is going on in 5 sec: http://picpaste.com/pics/Sans_titre-Sb2MkQyg.1379078842.png | 13:28 |
| stekern | _franck_: why are the bufclean vectors so large? | 13:32 |
| _franck_ | right [(1<<BUF_WIDTH)-1:0] shouldn't be that big | 13:34 |
| stekern | not sure that is the problem, but that was what I spotted within 5 sec =) | 13:35 |
| _franck_ | .BUF_WIDTH(8), | 13:35 |
| _franck_ | in my orpsoc_top | 13:35 |
| stekern | then it should be that big, but I can't guarantee that will work | 13:36 |
| _franck_ | you see ? You helped me in 5 sec ;) | 13:36 |
| _franck_ | it doesn't work with .BUF_WIDTH(8) | 13:36 |
| stekern | it might in the future ;) | 13:37 |
| stekern | so... it turns out to be really simple to drop in a memory controller with an avalon interface for the DDR3 in qsys | 13:38 |
| stekern | .. but, there's also an option to only generate an interface for the phy | 13:38 |
| stekern | that I want to explore in the future | 13:38 |
| stekern | make it work with wb_sdram_ctrl | 13:39 |
| olofk | stekern: I've been thinking if it would make sense to reuse the arbiter and buffer parts of wb_sdram_ctrl as a separate component | 13:40 |
| olofk | Perhaps it makes more sense to just have the possibility to add a FIFO for CDC on the master and slave ports in wb_intercon instead | 13:41 |
| stekern | olofk: interesting idea | 13:48 |
| stekern | I agree it might make sense, at least as it is now | 13:49 |
| olofk | That would help also if we want to add some other backend than SDRAM | 13:50 |
| stekern | but if you want to make it more advanced with access reordering you kind of want the knowledge of what's happening on the different ports | 13:50 |
| stekern | but the FIFO for cdc in wb_intercon isn't a bad idea anyways, and it might then be possible to remove _that_ part from wb_sdram_ctrl | 13:52 |
| olofk | Yeah, that's true. You need the arbiter tightly coupled to take decisision about reordering | 13:54 |
| olofk | I feel that if one or two more modules are added to wb_intercon, I can justify breaking it out to a separate project too :) | 13:57 |
| stekern | hehe | 14:00 |
| stekern | "playing the breakout game" takes a new dimension | 14:02 |
| stekern | I've almost forgot that the qsys generation haven't been sorted out... | 14:04 |
| stekern | you were hinting about a 'gen' command, I think that should go under that as well | 14:04 |
| stekern | because I'd get pissed if it started to regenerate that thing everytime I do a build | 14:05 |
| stekern | it's slow... | 14:05 |
| olofk | Are you storing the generated files now? | 14:05 |
| stekern | I'm storing them in build/src/qsys | 14:22 |
| olofk | k | 14:22 |
| olofk | I think I would choose to check them in with the system when it's reasonably stable | 14:23 |
| olofk | But autogenerated code is always a bit problematic. | 14:23 |
| stekern | I refuse to do that! =) | 14:27 |
| stekern | especially since it's easy to automate it | 14:29 |
| olofk | But you just said it's slow to regenerate it? | 14:35 |
| olofk | Oh well. I'm off | 14:37 |
| stekern | yes, it's slow to regenerate it, it takes perhaps 5 minutes | 14:47 |
| stekern | so it doesn't matter so much for a "first build", but if you are developing on stuff around it you'll get frustrated by it | 14:48 |
| crbowman | I've downloaded openrisc via svn. I'm trying to synthesize using DC but I'm running into a few issues. I have to take the provided synthesis script and TCLize it since the DC I have access to will only allow me to run TCL scripts. I think I've got the script right but I seem to have one issue. Several of the modules are unresolved during linking or compiling. It seems to be related to parameterization. For instance or1200_wb_biu is being instantiat | 18:58 |
| knz | crbowman: your sentence was truncated | 19:05 |
| crbowman | I've downloaded openrisc via svn. I'm trying to synthesize using DC but I'm running into a few issues. I have to take the provided synthesis script and TCLize it since the DC I have access to will only allow me to run TCL scripts. | 19:06 |
| crbowman | I think I've got the script right but I seem to have one issue. Several of the modules are unresolved during linking or compiling. | 19:06 |
| crbowman | It seems to be related to parameterization. For instance or1200_wb_biu is being instantiated twice with parameter 4 which happens to be the default for that parameter value. | 19:06 |
| crbowman | When the parameter value is overridden via the instantiation I get unresolved references, when I remove the override and let the default get used (which is the same value) then or1200_wb_biu is not unresolved. Has anyone seen this issue? | 19:06 |
| mschulze | Hi! Can someone tell what I have to do if I want to remove an IP core in a board definition? One example is the VGA core, I removed it from top level entity, from the wishbone bus, from the orpsoc-defines verilog file, but quartus still complains that the file "vga_defines.v" is missing. The same for other cores. What am I missing? | 20:11 |
| _franck_ | olofk: this line transactions = int "Number of wishbone transactions to run in test bench" in wb_intercon.core generates this error: | 20:38 |
| _franck_ | http://pastie.org/8323862 | 20:38 |
| olofk | _franck_: Hmm.. I wonder if that is because wb_bfm registers the same argument. Could be a python 3.3 problem. I'll try to remember to take a look at it. In the meantime, you can try to remove the transactions = ... line from wb_bfm | 22:44 |
| --- Log closed Sat Sep 14 00:00:55 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
