IRC logs for #openrisc Wednesday, 2014-07-23

--- Log opened Wed Jul 23 00:00:31 2014
blueCmdwell, running Linux with atomics seems to work. Running a test program with a basic compare and swap seems to work just fine, adding a l.sw to polute the location also makes the atomic store fail, which is nice00:23
blueCmdthe worrysome thing is that without the value-check this "works" for glibc00:23
blueCmdwith the value-check busybox (init) freezes at boot00:23
blueCmdmy hypothesis: since the atomics in gcc are one-shot, the loop gcc generates to acquire lock might store something to the memory location00:25
blueCmdseems very odd that it would be the case though00:25
stekernblueCmd: there's also this test you can try:
maxpalnOvernight rethink - I was wondering why I didn't come across this problem when implementing Linux on our old silicon. I had disabled Cache'ing on that implementation (for another reason - lucky me!) - since performance isn't the prime aim of the first iteration of the design I am going to disable caches again and see if it allows linux to boot. I have my fingers crossed. If it works it will07:19
maxpalnbe buy me plenty of time to implement mor1kx...07:19
stekernmaxpaln: presumably just luck, the timing has to be right for the situation to happen07:41
stekernblueCmd: what's the point of this repo?
maxpalnstekern: I agree, whether the situation happens or not is pure luck - but without caches a TLB miss can't happen (if I understand the mechanism correctly) so disabling caches should avoid the problem. That's my working theory anyway...07:43
stekernno, tlb misses can happen without caches07:43
stekernmaybe that misconception comes from something I said earlier, that the TLBs *are* pagetable caches07:44
maxpalnah, ok - so it is pure luck!07:45
maxpalnoh well -07:46
stekernbut it's still a bit odd, it has to be a fairly odd situation, so just shifting code around a bit will probably remove it07:52
stekernand another thing that is even more odd, for that to happen, you'd need to have another exception taking precedence over the itlb miss in the first place, but there's no exceptions with higher priority than itlb-miss...07:56
stekern*and* rfeing into an itlb-miss can't be that uncommon08:00
blueCmdstekern: it's the openrisc SVN from opencores09:47
stekernblueCmd: yes I can see that, but I didn't ask "what does that repo contain" ;)09:55
blueCmdstekern: the point being to move to git and off opencores10:00
blueCmdI'm changing stuff quite aggressively  hoping that people will bring up their concerns or silently follow.10:01
stekernok, I don't think we want a repo full of mixed stuff without any history moved over from svn to
stekernif we want to do continous development on the subprojects in the opencores/openrisc svn structure, I think the way forward is to move them over as standalone projects with their full history10:03
stekern(like we did with or1ksim)10:04
stekernbtw, I already did this when opencores was down several days and I couldn't get to the arch spec on my laptop:
blueCmdstekern: oh, I didn't know that! well, openrisc-docs contains revision history10:07
stekernoh, yes it did... wonder why I got the impression that it didn't.10:11
stekernI still don't see the value of it though10:11
blueCmdstekern: you trust opencores more than github?10:12
stekernno, but there's just old cruft in that repo, so I don't care ;)10:13
stekernmy point is just, if we want the stuff from that on, split it up into 'real' projects then10:17
stekernor call it something sensible, like 'old-cruft-backup-from-opencores-svn'10:18
maxpalnWell, for what its worth - disabling the caches has indeed allowed Linux to boot. I think I'll archive this project, send it to my customer and branch from there to switch OR1200 for mor1kx - at least this way the customer can get up and running and are not waiting for me :-)10:20
stekernmaxpaln: sounds like a plan10:27
blueCmdstekern: I have an 'old-svn' branch on that project that is just that11:57
stekernthe old-svn branch doesn't work btw12:01
blueCmdstekern: hm?12:02
stekernbut the naming of that repo is confusing, and the mix of stuff in it so to. If I'm confused what its purpose is, how do you expect user to react on it?12:02
blueCmdstekern: I'm all for splitting it into parts. I just wanted it off opencores ASAP.12:03
blueCmdI removed stuff in the master branch that I knew was out of date12:03
blueCmdI left what I wasn't certain of12:03
stekernok, the 'old-svn' branch works now, it was broken this morning12:04
stekernI'd like that whole repo to be called openrisc-old-svn, that name can stick even after interesting stuff have been lifted out of it12:06
blueCmdstekern: SGTM12:06
blueCmdI propose lifting or1200 to a seperate repo12:07
stekernyes, and there's some rtos stuff that are of interest12:07
stekernsome of the repos are just static, with no expected development, but it's still nice to have a backup of them if someone for some reason want to dig them up at some point12:08
stekernlike orpmon and or_debug_proxy12:09
olofkI don't want to hurry this too much either. Carefully picking out projects is the way to got here12:09
olofkAnd openrisc-docs is very confusing12:09
olofkIf you just want a backup I think it's better to put on your own github account for now12:09
blueCmdolofk: well, my evil master plan is not backup - that's just the initial step12:12
maxpalnWooHoo - Linux really does boot now: :-)12:43
maxpaln# uname -a12:43
maxpalnLinux openrisc 3.13.0-rc2-or1ksim-12436-g77ed213-dirty #117 Tue Jul 22 01:23:39 PDT 2014 openrisc GNU/Linux12:43
olofkmaxpaln: Congratulations!12:43
olofkNow rinse and repeat with mor1kx :)12:44
ysionneaucongratz maxpaln :)12:44
maxpalnolofk: thanks - debugging new silicon, PCBs, IP and a12:44
maxpalnMemory controller has taken its toll....12:44
olofkBtw, will this work be published somewhere? Adding lattice support has been on my wishlist for a long time12:45
ysionneauyou used bullet time to shoot on gateware bugs12:45
olofkI'm especially interested in the ice FPGAs that you acquired from siliconblue12:45
olofkWell, Lattice's reputation in low power is very interesting overall12:45
maxpalnysionneau: exactly - I have really been at this for 3 years, it just seems like less to your mortals working in slow-time....12:45
maxpalnolofk: Yes, there will be a published version12:46
ysionneauahah :)12:46
ysionneauin your time base your worked crazy fast!12:46
ysionneauin our*12:46
maxpalnBut I want to publish against the most up to date - and on one of our eval boards12:46
maxpalnthe version I have at the moment is kinda custom for this project I have been working on.12:47
olofkmaxpaln: For further work you should definitely move over to FuseSoC12:47
maxpalnyeah, exactly12:47
olofkWell, we're here to help :)12:47
maxpalnI think the best way is to start from scratch with a fresh checkout, create a processor that is targetted at our ECP5 eval board and use this as the initial publication.12:48
olofkDid you ever run my wishbone BFM poor-mans-constrained-random simulations against the Wishbone interface on your DDR controller btw?12:48
maxpalnolofk: it was the cornerstone of my development work, without it I would have really struggled to debug the controller as far as I did. :-)12:49
olofkmaxpaln: Glad to hear this. I should definitely improve it to catch more bugs though12:50
maxpalnHowever, having found a few bugs that the simulations didn't highlight I would like to propose a couple of enhancements that would go a long way to catching all the bugs:12:50
maxpalnI need to look at the code to see if I can implement them - they should be straight forward. But in descriptive terms:12:51
maxpalnThe code currently writes to memory then reads it back straight away and via the same burst access type. It would be better to do a bunch of writes, then a bunch of reads - mixing and matching the burst types.12:51
olofkThat's a good idea. Might be easiest to just keep a separate array of expected values at all memory locations12:53
maxpalnYeah, that was how I was planning on approaching it -12:53
olofkIt will be a big f*in array though :)12:54
maxpalnyou could make it manageable by running on 1K addresses or something12:54
olofkYeah. And doing many runs instead to catch address-related bugs12:55
maxpalnexactly, have the testbench populate a 1K buffer with values, then perform a bunch of writes to the wishbone memory interface using random burst types, then read the values back using random burst types again - as long as the values match you have a win!12:56
maxpalnyou could even parameterise the buffer size - DDRX memories use pages that wrap at column boundaries - having a buffer that is larger than the column address space is an interesting test that took me a while to implement.12:57
olofkYes, having buffers larger than page size is probably a good idea12:59
maxpalnThe other one is implementing some simple wait states - the simulation immmediately starts a new transaction after the previous one ends. In the real world there are usually some more idle cycles for the controller - this one is more implementation specific but the simulation never exercised the 'remain in idle' condition of my state machine. There happened to be a bug in that code!!12:59
olofkrandom back-off times is on my TODO list :)13:00
olofkDid you get my invitation btw?13:00
olofk(just checking to see that it reached you)13:00
maxpalnYep, it got to me - thanks13:01
maxpalnI am looking forward to it :-)13:01
olofkGlad to hear13:01
maxpalnI still need to reply to you though - it's on my list, I assumed I had a few days :-)13:01
olofkNo stress at all. It's just that some company mail servers are a bit picky about accepting mail from gmail/hotmail/yahoo addresses13:02
maxpalnit's all good!13:02
maxpalnbut otherwise, the BFM simulations were very helpful. Glad they were there!13:03
stekernalso, zero wait state read->write->read turnaround busaccesses should be tested13:06
stekernand back-to-back bursts13:07
olofkstekern: Totally agree13:07
stekerni.e. accesses where stb&cyc aren't de-asserted between bursts13:08
olofkstekern: Did we ever work out if that was allowed in the wishbone spec?13:08
stekernbyte-selects without the lower bits in the address is another test13:09
stekernI have never had any doubts that it wouldn't be allowed13:09
stekernwhy would it be disallowed?13:09
olofk0001, 0010, 0100, 1000, 0011, 1100 and 1111 should be the masks to test, right?13:09
olofkfor 32 bit13:10
stekernyes, 1001 for instance isn't a valid mask13:10
olofkand 0020 isn't either :)13:10
stekernis that in dinary?13:14
olofkI'm thinking about implementing a change in FuseSoC btw, to allow multiple .core files in a single directory. That way we could pull in larger repositories (like milkymist) instead of doing like we're currently do for mmuart and minimac13:14
maxpalnstekern: if stb and cyc are not deasserted what indicates the end of the cycle?13:15
olofkmaxpaln: cti=11113:15
maxpalnAh, ok - does the spec allow this?13:15
olofkThat's what we're discussing :)13:15
maxpalnI think one of CYC or STB and CYC need to deassert13:15
maxpalnif it just CYC then it is a BLOCK cycle (which is not tested in the simulation!)13:16
maxpaln(I think)13:16
olofkstb is more like a data valid, so that doesn't really indicate that the cycle is over13:16
olofkYou can deassert that in the middle of a transaction if the sender needs to wait to produce more data13:16
olofkBut they are generally just &-ed together13:17
maxpalnI believe you can also change from Write to Read by keeping CYC asserted and deasserting STB, toggling WE, then asserting STB again13:17
maxpalnI looked at this bit of the spec a LOT13:18
maxpalnI hope I understood it correctly :-)13:18
olofkIt's a bit hard to decipher in some areas13:18
maxpalnah, but I think stekern is right - it would appear to be valid to insert zero wait states -13:24
maxpalnThe spec always describes deasserting STB and CYC at the end of a burst, but it never states it as a rule - at least not as far as I can see.13:25
maxpalnI wonder what my controller would do in this situation! :-)13:25
stekernno, it's not a rule. a cycle is always terminated by an ack, and a following cycle can immediately follow13:33
maxpalnyep, that is what I read too13:34
maxpalnor rather, how I understood it when i read it13:35
maxpalnso the random number of wait states should vary from 0 to n (where n is probably 6-10)13:35
stekernright, that'd make sense13:45
olofkstekern: I have a project in the works where I probably want do DMA, kind of like your wb_fifo idea16:14
olofkAn external device will push data into the FPGA, and I want to make a wb master that pushes this data to another peripheral or to RAM16:15
olofkI could do something like the buffer descriptors in ethmac to control this, but I'm thinking about something simpler16:17
olofkJust adding a wb slave interface where I have five registers. start address, end address, write pointer, read pointer and an overflow flag16:17
olofkand an enable flag16:17
olofkSo I allocate a memory area and set up the start and end address accordingly16:18
olofkThen I just enable it, checks the write pointer to see if new data has come in and update the read pointer when I have read a data block16:19
olofkOverflow is set when the pointers overlap16:19
olofkIf I can do this somewhat modular, I think it could be useful in other places as well.16:20
olofkSo, I'm looking for some second opinion/brainstorming to see if this is general enough to be useful16:20
olofkActually, it would be the opposite of the wb_fifo, come to think of it16:21
olofkThis is for streaming data, so there will be no packet boundraries to think of16:21
olofkThere are of course a lot of extra features that could be implemented, like configurable burst sizes to get a good bus utilization and so on16:27
olofkand it could probably be extended to support packets as well16:27
stekernyes, that sounds useful, only one question - so, is the idea that this core is completely stand-alone (with some well-defined interface) or is the idea that you embed it into your core instead of constantly rewriting a wb-master whenever you want DMA functionality?16:31
olofkThe idea is to have a well-defined interface (basically a FIFO), and users can either put them side-by-side or drop them into their core16:42
olofkFor my own project, I'll probably make a convenience wrapper module that instantiates the wb-master-thingie together with my peripheral driver16:43
olofkGot to run now. Going to play soccer with some friends, which is like the worst idea ever in this heat16:43
blueCmdolofk: stekern:
juliusbso, interesting discussion on the mailing list18:05
juliusbI had no idea that had disappeared into the ether18:05
juliusband is Marcus really uncontactable these days?18:05
juliusbAnyway, I think the decoupling of repos from OpenCores was basically a foregone conclusion once people started committing most work to github18:07
juliusbThere's practically no commits of code to OC SVN compared to github18:08
juliusbSo that's certainly not an issue. The issues, as  I see them, are mailing lists and website (wiki?) and that's it?18:09
juliusbThe entry point has basically always been the opencores site, it's the second link on google after the wikipedia entry18:10
juliusband blueCmd  I agree completely that the main page there needs a good tidy18:10
juliusbI can't speak for the rest of the OpenCores projects, I agree with Jeremy, you might be biting off more than you can chew by taking what is on OpenCores lock stock and putting it up elsewhere. You could probably write a good script to scrape what little information also lives on the projects' pages and put that onto github in some form, too18:14
juliusbmaybe that'll gain some traction, I don't know. Most hackers/hobbyists/enthusiasts now just put their cores on github anyway, there's probably a handful of active projects on OpenCores, and I suspect any alternative will be equivalently active. I can't say OpenCores is a hotbed of collaboratively developed IP cores anyway (aside from the flagship project, of course)18:16
juliusbmost projects with more than a couple of people contributing either start their own thing, or as I mentioned, stick it on github and host their own domain with information on it. So I guess I'm saying, as crap as OpenCores is, I'm not convinced any alternative will make things much better (there's already and various other academia-based sites with stuff)18:20
juliusbI'd like to be proven wrong, though :)18:24
olofkI had no idea about the redirection either21:13
olofkhmm... what should I call my new core? It's not a full DMA implementation, so I want to avoid that21:22
olofkI settled for wb_streamer for now22:35
blueCmdjuliusb: the -> freecores github is mainly to replace opencores and let it die in peace.23:55
blueCmdjuliusb: "foregone conclusion once": yes, that's a big point that I'm trying to make23:56
blueCmdmy idea is that the big work is already done, but we're still having opencores in the critical path for a new user or for our "release" process23:57
blueCmdwhich I don't like23:57
--- Log closed Thu Jul 24 00:00:33 2014

Generated by 2.15.2 by Marius Gedminas - find it at!