IRC logs for #openrisc Friday, 2013-09-13

--- Log opened Fri Sep 13 00:00:54 2013
poke53282stekern: Patch send to mailing list. Finally the varargs problem is at least documented.00:29
stekernpoke53282: 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 orconf03:09
poke53282Nice, are there other parts of the ABI that needs revision?03:25
stekernlet'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 it03:28
stekerncall-saved, callee-saved register order is one03:28
poke53282Of course, would be a bad idea to do gradual change of the ABI. People will get crazy.03:29
stekernexactly, so we need to have a good plan of what should go into v2 before we start hacking on it03:31
poke53282Then 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
stekernpoke53282: ok, thanks for the heads-up of that04:51
stekernI will probably take that patch and apply it to a seperate tree so it doesn't get lost too04:55
stekernand we need to sync against upstream to get the native gcc bugfix and the tex fix too04:56
stekernI'll try to switch into toolchain mode next week sometime, right now I have too much fun playing with the sockit board ;)04:57
stekernI can read and write the DDR3 connected to the ARM from the openrisc side now04:57
stekernbut it's odd, all addresses are shifted by 4 bytes compared to what the ARM sees04:58
stekernah, no, it looks like the first access always returns garbage and the rest is shifted05:25
stekernso I probably latch the data at the wrong clock edge05:26
stekernnow it works05:50
poke53282I like your toolchain mode more than your FPGA mode ;)06:01
stekernweren't you in progress of purchasing an FPGA board though?06:02
stekernmaybe you will appreciate the FPGA mode more after that ;)06:03
poke53282But 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
poke53282Yeah, probably. I have not ordered yet. Shame on me.06:04
stekernno, this particular DDR3 access is dead simple, the hps (hard processor system) have an AXI port available for the FPGA fabric to use06:05
stekern...and then that is translated to an avalon bus by the altera tools06:06
stekernand avalon is very easy to access from the wishbone bus (the bus protocol we use)06:07
stekernthe only thing that differs are really how burst accesses, but if you don't support that it's just a matter of hooking up signals06:07
stekern*how burst accesses are handled06:08
stekernnow, 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 FPGA06:08
stekernthe second DDR3 will need more work to get access to06:09
stekernso, I basically (will) have 2GB of DDR3 accessible by the openrisc core06:10
poke53282nice, hopefully it will be fast too.06:14
poke53282So, I have to jump into my bed.06:14
stekernnighty night06:15
olofkstekern: Good work. My sockkit is in a packed in a box now unfortunately.07:09
stekernkeeping 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 sockit07:21
stekernthe rise of the sockittens!07:24
olofkGo Sockittens! Go!07:25
stekernolofk: wb_intercon_gen feature request, break lines at 80:
stekernperhaps it's easier to just split it so that each signal is on its on line07:28
stekernolofk: what kit for your socks are you speaking about btw?07:30
stekernneedle and thread?07:31
olofkI think we need a sock building workshop at orconf07:32
olofkstekern: Yeah, that's the one I have. I still don't understand how you managed to squeeze in an OpenRISC in the tube07:32
olofkstekern: Yeah, I guess that the lines can become quite long. I'll fix that07:33
stekernolofk: 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 it07:35
stekernnext step for sockit is to get the FPGA DDR going07:47
olofkPlease don't talk about DDR right now07:49
olofkI've been spending the last month hunting down a bug in a generated DDR2 controller07:49
olofkI've been tempted more than once to just rewrite the fucking controller myself07:52
olofkor is it hard DDR3 controllers in the SoC Cyclone?07:52
stekernthe 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 too07:57
olofkIs there a git cat that I can use to look at a file at a certain revision?08:11
olofkor git diff between a VCS-controlled file and another file08:13
stekerngit show08:21
stekernno, that's not what you asked for08:25
stekernactually, it can do08:28
stekernI didn't know it could though08:28
olofkAnyone has recommendations for a text based diff tool? I use meld usually, but I don't have X forwarding now08:29
stekerngit show <commit>:<file>08:29
olofkThanks. That's good to know08:29
stekernI usually just use plain diff when in text mode08:29
stekernand diffmerge in X08:30
stekernvimdiff is pretty godd I think, I've only briefly tested it though08:31
olofkvimdiff as in crazy-ass-vi-commands-diff?08:33
_franck_just use meld08:34
olofk_franck_: Don't have any display :(08:35
_franck_ah ok sorry08:36
olofkBut I found a way. Running a shell in a split buffer in emacs where I can have the diff output08:37
stekernhas meld became better, last I tried it it wasn't good enough08:38
olofkI think it does a good job08:38
stekernI'd like to switch to that from the closed source diffmerge, but it just didn't cut it08:39
stekerncan you turn off that crazy mode where it shows the diffs like this?
olofkWhat's the problem?08:40
_franck_this mode is great !08:41
stekernthe code that isn't changed isn't lined up together!08:41
olofkIf you scroll it will align08:41
stekernthis is how it should look like:
stekerncan you edit in the window on the right?08:46
stekernI mean, manually08:47
stekernI think it couldn't before (or then that was kdiff3)08:47
stekernthree-way merges?08:48
stekerndirectory diffs?08:48
_franck_(three way) at least when I use it with git08:49
_franck_directories, yes08:49
stekernmaybe it was just the ugly diffs that put me off with meld08:49
olofkIt handles git and svn too, but not clearcase09:02
olofkstekern: 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 ports09:48
olofkI vote for dropping the m2s suffixes on the interface and bring back _i/o instead09: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_add it only on the data wire signals09:53
olofkI think it can be good to have it on all signals so it looks more symmetrical09:54
olofkBut the names you have for the interface ports is the same that I would like to have09:55
olofkotoh, you can name the signals in your orpsoc_top to whatever you want10:00
olofkThis has turned out to be an excellent bike shedding discussion :)10:01
stekernolofk: I think I agree on removing m2s on wb_intercon interface and bring back _i/_o11:44
stekernI did that because it makes AUTOINST work11:45
stekernbut if you provide an instantiation with the generation that becomes moot11: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 work12:00
_franck_it can't download github archive. However, wget the same link works12:03
_franck_no wget does not work, need to find why12:07
_franck_export http*s*_proxy=http://.... was the solution12:13
olofk_franck_: There is support for setting proxy in the python functions. That might go in orpsoc.conf12:15
olofk_franck_: Does orpsoc work when you export the proxy stuff too?12:18
_franck_have had http_proxy exported. I needed to export https_proxy12:19
olofkGreat. Then we don't need to fix orpsoc12:25
stekernaccording to this, there should be 2 hard memory controllers:
_franck_stekern: I'm sure you'll find what is going on in 5 sec:
stekern_franck_: why are the bufclean vectors so large?13:32
_franck_right [(1<<BUF_WIDTH)-1:0] shouldn't be that big13:34
stekernnot sure that is the problem, but that was what I spotted within 5 sec =)13:35
_franck_in my orpsoc_top13:35
stekernthen it should be that big, but I can't guarantee that will work13:36
_franck_you see ? You helped me in 5 sec ;)13:36
_franck_it doesn't work with .BUF_WIDTH(8)13:36
stekernit might in the future ;)13:37
stekernso... it turns out to be really simple to drop in a memory controller with an avalon interface for the DDR3 in qsys13:38
stekern.. but, there's also an option to only generate an interface for the phy13:38
stekernthat I want to explore in the future13:38
stekernmake it work with wb_sdram_ctrl13:39
olofkstekern: I've been thinking if it would make sense to reuse the arbiter and buffer parts of wb_sdram_ctrl as a separate component13:40
olofkPerhaps it makes more sense to just have the possibility to add a FIFO for CDC on the master and slave ports in wb_intercon instead13:41
stekernolofk: interesting idea13:48
stekernI agree it might make sense, at least as it is now13:49
olofkThat would help also if we want to add some other backend than SDRAM13:50
stekernbut if you want to make it more advanced with access reordering you kind of want the knowledge of what's happening on the different ports13:50
stekernbut 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_ctrl13:52
olofkYeah, that's true. You need the arbiter tightly coupled to take decisision about reordering13:54
olofkI 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"playing the breakout game" takes a new dimension14:02
stekernI've almost forgot that the qsys generation haven't been sorted out...14:04
stekernyou were hinting about a 'gen' command, I think that should go under that as well14:04
stekernbecause I'd get pissed if it started to regenerate that thing everytime I do a build14:05
stekernit's slow...14:05
olofkAre you storing the generated files now?14:05
stekernI'm storing them in build/src/qsys14:22
olofkI think I would choose to check them in with the system when it's reasonably stable14:23
olofkBut autogenerated code is always a bit problematic.14:23
stekernI refuse to do that! =)14:27
stekernespecially since it's easy to automate it14:29
olofkBut you just said it's slow to regenerate it?14:35
olofkOh well. I'm off14:37
stekernyes, it's slow to regenerate it, it takes perhaps 5 minutes14:47
stekernso it doesn't matter so much for a "first build", but if you are developing on stuff around it you'll get frustrated by it14:48
crbowmanI'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 instantiat18:58
knzcrbowman: your sentence was truncated19:05
crbowmanI'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
crbowmanI 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
crbowmanIt 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
crbowmanWhen 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
mschulzeHi! 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
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_bfm22:44
--- Log closed Sat Sep 14 00:00:55 2013

Generated by 2.15.2 by Marius Gedminas - find it at!