IRC logs for #openrisc Wednesday, 2013-09-11

--- Log opened Wed Sep 11 00:00:51 2013
stekernwe have contact:
olofkstekern: Congratulations. What was the problem?06:06
olofk_franck_: Hmmm.. I'm not sure that's the original source06:07
olofkBut at least it might be an unchanged copy06:07
stekernolofk: you need to configure the pinmuxes from software06:14
stekernand it has to be done in u-boot-spl06:14
olofkHmm.. I find a lot of verilog models on microns website, but for the particular ram we're using, I can't find anything06:19
stekernfinding instructions how to replace spl wasn't trivial neither06:26
stekernI managed to screw up my sdcard06:26
stekernI dd'ed the image to the wrong partition...06:27
stekernI also have discovered that you can "brick" the device with a broken vjtag setup...06:28
olofkbrick the sockit?06:29
stekernactually, maybe it's not the vjtag setup that I have trashed06:30
olofkSo far I have found verilog models for 19 of 50 Micron SDRAM memories06:30
stekern"brick" as in: need power toggle to remove the broken fpga configuration06:32
stekernI cleaned up the pll stuff a bit, removing the megawiz generated files and just instantiated the pll directly in clkgen.v06:35
stekernbut I accidently connected the active low reset to the active high reset input of that instantiation...06:35
stekernclassic mistake, wrong polarity of reset signals06:36
stekernolofk: have you considered adding 'scripting' support to orpsoc?06:40
stekernI imagine it would be fairly simple to allow python scripts in cores/systems be called from orpsoc06:41
olofkstekern: Yep, I'm planning to add that at some point06:44
olofkIt's probably needed06:44
stekernneeded or not, it'd be cool ;)06:45
stekernand it'll make it a lot more powerful tool06:45
olofkYes, and again I'm looking at gentoos ebuild format07:07
olofkBut they use shell scripts, and I do not want that07:07
olofkSo the idea is to have config options that makes it possible to run scripts at different stages07:08
olofkLike pre_compile=do_some_preprocessing_stuff.py07:08
olofkBut I think that the internal APIs need to be documented and somewhat stable before that07:09
stekernyeah, sure07:11
_franck_olofk: about the sdram ram model, when I said original source I meant unmodified07:54
olofk_franck_: Ah ok. I see08:12
knzI got my new hard drive \o/  (that means I can now install the EDA tools properly)09:30
stekernby transforming google-fu into emacs-fu I have came up with this for all verilog-mode indentation haters:
olofkKilling auto-newline is a godsend too09:38
olofkWe could of course have a full-scale war about the tab width09:39
stekernno, a tab is 809:39
stekerneverything else are spaces09:39
olofkI'll take it for a test-drive09:40
stekerngo ahead, drive it with caution, it's still a low-miler ;)09:41
stekernmight need some carburator adjustments etc09:41
stekernI think I actually prefer to kill verilog-auto-indent-on-newline too09:42
olofkTo get rid of trailing spaces on empty lines?09:43
olofkFound a problem with your verilog mode.
stekernyes, to get rid of trailing spaces on empty lines09:57
stekernand I found myself constantly going back erasing them after a newline09:58
stekernolofk: I SAID DRIVE CAREFULLY!09:58
stekernah, but you know what, I think it's just that it doesn't know how to fix it when there are already spaces in there10:00
stekernno, that's not it, it's because you have the ( in the wrong place ;)10:04
stekernno, it's still odd...10:06
stekernit doesn't do it on all files even10:10
olofkThat's weird10:13
olofkI tried a few different placements of the ( too, but it didn't help10:13
stekernyeah, it's unrelated10:13
stekerntry editing orpsoc_top.v in generic for example, that works fine10:14
olofkAre there any leftover verilog-mode hints in that file?10:14
olofkStarted a fresh file with just a module header. Same problem10:15
olofkSo it's not due to existing spaces10:15
stekernI think it might have to do with the parameters10:20
olofkverilog parameters?10:21
olofkHmm.. I added a parameter, and now the inputs are indented one space from the first one10:37
olofkAnd if I add two parameters, they get the crazy indent10:37
stekernmaybe there's a bug somewhere in verilog-mode doing that10:38
olofkCan I reload my .emacs without shutting down emacs?10:38
stekernI mean, I think you can, but I don't know how10:39
olofkM-x eval-buffer10:40
olofkDoesn't seem to be all that simple though10:41
knzyou can't "re-init" emacs10:42
knzeval-buffer is the best you can have10:42
knzbut it's not equivalent to a reload10:42
olofkverilog-indent-lists t helped a lot10:43
olofkports and parameters aren't lined up with each other, but it looks a lot better10:44
stekernmogna parameternamn! =)10:46
stekernbut no, verilog-indent-lists t doesn't help a bit, will screw up module instantiations10:46
olofkHmm.. I wonder if our verilog-modes differ to begin with10:47
stekernand the inputs should be one tab inwards10:47
olofkI'm not seeing any problems with module instantiations here10:47
olofkAs a side note. My tabs don't seem to be 8 spaces wide10:48
stekernit only inserts one tab and doesn't line it up with the (?10:49
olofkI get two tabs and two spaces on the first line, and three tabs on the rest10:49
olofkDoes pastie keep the tabs/spaces?10:50
stekernit should look like this:
stekerntaste issue of course, but that's my how I'd like it10:51
knzquestion: can I use the same binutils install for both the cores with and without delay slots?10:52
olofkBut won't that be a mess when you have signal names of different length. If I copy/paste that piece of code it looks like crap10:53
stekernknz: yes you can, it'll install them as multilibs (iirc)10:54
knzbut the binutils are not libraries10:55
stekernolofk: now I'm not following, what does the signal names10:55
knzI don't see how multilibs are relevant here10:55
stekernknz: no sorry, I "read" or1k-src from binutils10:56
knznow I'm confused10:56
olofkstekern: It's more of a general problem with tabs I guess. It just looks awful when you don't have tab width 810:56
knzisn't the or1k-src repo exactly about binutils?10:56
knzthe README-OR1K in there only mentions building the binutils10:57
stekernolofk: but you do have a tab width of 8, everything else is insane ;)10:58
stekernknz: that README should be removed, it's obsolete10:58
stekern(I think, let me look)10:58
stekernyeah, quickly forget what that says10:59
knzmaybe put a link to in there11:01
stekerngood idea11:07
knzsilly thing11:12
knzthe binutils configure script uses ISL_CHECK_VERSION assuming it does an "at least" check11:13
knzbut the m4 macro is atually an exact check11:13
knzso my 0.11 is not recognized :(11:13
_franck_olofk, stekern : don't you have this king of thing in emacs:
_franck_showing you white space and tabs ?11:18
olofk_franck_: Not sure actually11:19
olofkI have to use my usual emacs answer. There probably is a way, but I don't have a clue how to do it :)11:20
stekern_franck_: yes there are11:20
stekernit's called global-white-space mode11:20
_franck_with this enabled you won't mix tap/space ever :)11:21
stekernit also shows trailing whitespaces (as I demonstrate in the screenshot)11:24
stekernthe grayish stuff is tabs11:24
olofkDoesn't work on my emacs :(11:24
stekern*greyish stuff are11:25
stekernwhat emacs do you have?11:26
olofk22.3.1, the GTK version11:27
olofkDoesn't work in -nw mode either11:28
stekernheh, why not?11:28
olofkNo clue11:29
stekernare all the wb_intercon changes just related to testbenches?11:30
olofkstekern: No, it's updates to the module ports that are done in preparation of the wb_intercon generator11:30
olofkI wasn't happy with the wb_mux design, so that's the main reason for the updates11:31
stekernlet me rephrase that, do I have to change anything in my sockit WIP11:32
olofkNow it's just so incredibly awesome that it blows my mind by looking at the code11:32
olofkyes, if you use wb_intercon.v or wb_mux.v from the wb_intercon core11:32
* stekern looks at _franck_11:33
olofkSorry s/wb_intercon.v/wb_arbiter.v11:33
olofkTake a look at the or1200-generic system11:33
olofkIt's been updated11:33
stekernyes, but there was only changes from dat_o to rdt (which I think is not so smart)11:34
olofkAh yes. That would be the only change for interconnects with a single slave11:35
olofk(which is still up for discussion)11:35
olofkSo wb_mux wasn't used before in or1200-generic (which is why you didn't see any changes)11:36
olofkBut the last commit last night added a UART and hence a wb_mux in wb_intercon11:36
stekernah, ok11:36
knzside question: is there any or1k-based soc with anything else than buses as interconnect?11:37
stekernolofk: but that's also just tb changes?11:37
olofkstekern: Depends on how you see it. In or1200-generic I decided to put everything in the bench directory since the whole system is just meant for simulation, so yes, there it's only tb changes11:40
olofkknz: What do you have in mind that is not buses?11:40
stekernok, well, I'll figure it out11:40
knzolofk: on-chip packet switching11:40
stekernwhy is it just meant for simulation btw?11:40
olofkknz: Still buses :)11:41
knzolofk: no, not strictly11:41
knzat the wire level you're right but then the system model has a very different behavior to contention on shared units11:42
knzalso, I would not call a pair of wires with only 1 slave and 1 master a "bus"11:42
olofkstekern: I don't want to add clock and reset generation that would be needed to build it for real.11:42
knzjust a "pair of wires"11:42
olofkBut I will probably move it it rtl/verilog, because then you can use it as a subcomponent in another system where you have the techonlogy-dependent stuff11:43
olofkI've been trying out a lot of ideas. Some good... some not so good11:43
olofkknz: I think I might have heard of someone doing something NoC-related with OpenRISC, but you would need to have different bus interfaces on all the cores then11:45
olofkWishbone isn't well suited for NoC as it is today11:45
knzthat is why I was asking11:45
stekernolofk: fair enough11:47
olofkI don't think we would benefit from NoC in most of our applications really.11:50
stekernolofk: so, it's this commit that has the core changes that breaks the interface, right?
knzolofk: thanks for your comments11:50
knzother question, as I am currently reviewing mor1kx_rf_cappuccino.v11:51
knzstekern: maybe that one's for you11:51
olofkstekern: Yep, that should be it11:51
knzis it the case that the register file gets activated and read from at every cycle, regardless of whether the read is bypassed from a later pipeline stage?11:51
knzI ask because I only see a select on the rf_ram_o, not the _en bit11:52
stekernknz: yes11:52
stekernbut there is no real reason why it couldn't be gated by the bypass signal11:53
knzI can see one: timing11:53
knzthat means the read cannot be done in parallel with reading the bypasses11:54
stekernyeah, but I mean theoretical11:54
stekernyeah, that is true, was a while since I poked at that, so not really context switched in ;)11:54
knzI'm working on a core design where the RF is much larger, and thus power hungry11:55
knzso I 'm exploring ways to save up there11:55
stekernmmm, but should be doable12:03
olofkAll right then. Went through all the 201 SDRAM models on Microns website. There are _no_ simulation models for the mt48lc16m16* parts12:05
olofkIn total, 98 out of 201 has a verilog model, so there might be a chance that one of those could be used12:06
olofkAha! I was wrong12:25
olofkBut the newest one I can find is from August 2001. The one in ORPSoC is updated June 200212:25
stekernolofk: I can't get my head around how the MATCH_ADDR and MATCH_MASK works12:28
stekernnm, now I do12:30
stekernno... maybe I'm sleep deprived, but how can I get slave 0 selected between addresses 0x90000000-0xffffffff?12:43
olofkstekern: Hmm... that won't work12:59
olofk0x80000000-0xffffffff would work though13:00
olofk(and make more sense)13:00
olofkIf you want to block 0x80000000-0x8fffffff that could be done too13:01
olofkOr am I missing a use case here?13:02
olofkaha! The model on Microns website that is date 08/2001 contains a file that is last updated 06/2002. I found the original!13:04
olofk#openrisc, my private pastie13:05
stekernmine too13:09
stekernyeah, I know that 0x80000000-0xffffffff would work, and it's fine for my use case13:09
stekernkind of wasteful if you have 4 gigs of ram13:09
stekernor am I missing something13:10
mschulzeHi all!13:11
stekernthe sel signal seemed more flexible13:11
stekernheh, now I'm all confused by the rdt/sdt/dat_o/dat_i changes... I changed all the signals on wb_data_resize too...13:15
olofkstekern: Yes, the sel signal was more flexible. I figured that the flexibility wasn't needed though. I might have been wrong there13:15
olofkstekern: Me too. I realize that I started a mess13:16
olofkand hi mschulze!13:16
stekernI vote for the m2s and s2m naming and keep the _dat name13:16
mschulzeAre you discussing the wishbone signal names?13:17
stekernolofk: it's all cool, you've got to through away one sometimes13:17
olofkmschulze: That or tab width :)13:18
stekernin the #openrisc church13:18
mschulzeI have got a comment on that too... :-)13:18
olofkmschulze: Welcome to the party. The tab is open and we have plenty of space for you13:19
mschulzeWhen generating wishbone arbiter files it would be helpful if the signal names within the arbiter and at the top level would contain the name of the core that is connected to the "port" and not only a number :-D13:20
olofkmschulze: You can take a look at
olofkThat has been generated from my wb_intercon generator13:21
mschulzeI really must have a look at your generator soon. At the moment I am a bit out of order because I have to do all that things that I haven't done the last months...13:22
mschulzeYour names look exact like generated ones working around the problem I had...13:24
olofkmschulze: Here is a preliminary version13:26
olofkI can provide you with a 30 day evaluation license for the generator13:26
olofkAfter you have signed the NDA13:27
mschulzeMy question is: Am I bound to the wishbone naming only at the interface to the IP cores or am I bound in other files too?13:28
olofkNot sure what you mean13:28
mschulzeThe signal names in the wishbone specification document13:29
mschulzeAre we bound to them in our generated files?13:30
mschulzeI have no NDA within your archive file...13:33
knzother question: who's responsible for the newlib/libgloss code?14:00
olofkmschulze: You can use whatever name you want internally in your cores14:03
olofkBut we should use the names in the spec for the interfaces. Note that I have _not_ used the name from the spec for the data signal from the slaves14:04
olofkBut I probably need to change this14:04
stekernknz: the one that touched it last ;)14:14
* stekern prays it wasn't me14:14
stekernknz: most of the code there have been done by jeremybennett and juliusb14:20
mschulzeolofk: I'm still waiting for your NDA or a hint that it has been a joke...14:22
olofkIt was a joke :)14:24
stekernI read DNA first...14:45
_franck_looks like it is now named OnRISC14:45
stekernI just realised I can copy-paste from the weblogs when I'm on the run14:50
stekernthere's just a bit of latency14:50
mschulzeolofk: Thanks, I'll look through it as soon as my time table allows it. Your approach looks more modular than mine. At the moment I am struggeling with some gitignore problems. As soon as they are done I am ready to release it to github although it doesn't work at the moment. There are missing module_defines.v files for modules that I don't use and I have to figure out, where they are referenced.15:07
mschulzeOh, sometimes I tend to build up a wall of text. Sorry. I have to leave now. Bye ;-)15:10
knzhi again17:24
knzfor or1ksim, the target is or32-elf, not or1k-elf, right?17:24
knznever mind17:25
stekernolofk: If you agree on the s2m and m2s naming, I could take on the fun job to rename all the signals across orpsoc-cores if you'd like17:52
stekernand sorry if I come out as a bit overcritical at times, overall I think it's really great what you've done with orpsocv3 and orpsoc-cores!17:53
stekern_franck_: this isn't right, right?
stekernah, yes it is, now I see where that comes from18:30
stekernit's a bit tricky when parameters are lower case and not declared in the same file18:32
stekernolofk, _franck_: the approach of having one wb_data_resize for a whole bytebus is not how it's intended to be used, right?19:01
_franck_well, why not ?19:03
stekernbecause it's not going to work with the olofk's latest changes19:03
_franck_ah ok :)19:03
_franck_I was about to take a look at this19:03
stekernI think my criticism over MATCH_ADDR and MATCH_MASK might have been slightly misdirected too19:04
stekernso, if I understand things correctly, the idea is to have only one wb_mux for the whole data buss, and each peripheral get picked with the MATCH_ADDR and MATCH_MASK (possibly as fine grained as just the registers it covers)19:08
stekernthen on each byte-peripheral you hook up a resizer19:09
stekernand it's not going to work with a single bytebus in the scenario where you'd have 0x90000000 = byte, 0x91000000 = word, 0x92000000 = byte19:11
_franck_yes, you have to have on resizer per mux output19:14
_franck_let me size how it works in my de119:15
stekernI'm pretty familiar with how it works there, since I copied that as a base for sockit ;)19:15
_franck_ok a resizer then a mux19:16
stekernit's fine there since all peripherals are bytebussed19:16
stekernperhaps wb_mux could always default to the '0' bus and everything else would just be masked out of that19:18
stekernthat would solve the "waste a lot of memory space" problem19:18
_franck_do you think waste of memory space is a problem ?19:19
stekern"problem", but yes. It's ugly if nothing else19:20
stekernbut, actually, you can get the wb_mux to do the "default to" as it is now19:20
stekernjust set that RAM mask to 0x00000000 and addr to 0x00000000 an put it last19:22
_franck_I'll see how the wb_intercon_gen is doing this thing because I'd like to remove all this bus part from my top19:25
stekernyeah, I'm starting to get the same urge19:26
_franck_I need a pen to draw diagrams for that :)19:29
_franck_as you said, we would have only resizers in the top....until olofk adds support for resizer in wb_intercon_gen ;)19:35
stekernyup, you can of course wrap the generated intercon.v and have the resizers there... but I'm not sure if that's any better than to have them in top19:42
* _franck_ is going to loose 15 minutes with this tab/spaces thing :)19:43
stekernwas that your 15 minutes of fame that went now?19:43
_franck_? I don't get it19:45
stekernah, it was a joke ;) it's a famous Andy Warhol quote, "everybody gets 15 minutes of fame"19:46
_franck_ok, I knew it was a joke but I wasn't smiling  so I knew I didn't get it :)19:48
stekernwell, it wasn't very funny, so... =)19:48
stekern_franck_: have you tested to run olofk's work-in-progress intercon_gen?19:49
_franck_no I'm about to do it19:51
stekernah, now it worked19:51
stekerninvoke it by: python intercon.conf19:51
stekernthis is impressive stuff19:52
_franck_I think we should (at least me) learn python to give olofk a hand19:54
stekernyeah, me too would need to learn more19:54
stekernI've only dabbled with it19:54
_franck_it would be great to have the module instantiation skeleton on the generated intercon.v20:03
stekernyou can get that with AUTOINST though20:11
_franck_that's why I should try to use emacs...20:12
stekernnow if only the wires could be AUTOWIREable20:26
stekernthey are, but what I mean is that also the destinations would be AUTOINSTable20:36
_franck_the intercon.v use an arbiter for dbg_d, cpu_i and cpu_d20:48
_franck_so we can't take advantage of your wonderful port cached sdram controller20:49
_franck_I need to review my intercon config file20:50
stekernah, you just have to configure it a bit differently20:50
_franck_yeah tell mem is imem for exmaple20:51
_franck_let's see what you've done20:51
stekernyes, a seperate slave for each port20:52
_franck_wb_intercon_gen doesn't want my led to blink :( I'll that tomorrow21:27
stekernI'm not done hooking it up21:32
stekernI'm trying out the s2m and m2s notion to see if it makes sense21:33
--- Log closed Thu Sep 12 00:00:52 2013

Generated by 2.15.2 by Marius Gedminas - find it at!