IRC logs for #openrisc Wednesday, 2016-09-21

--- Log opened Wed Sep 21 00:00:21 2016
shorneolofk: I see its still down today, I dont think I have seen a backup of the wiki (I was actually just pulling it from google cache)06:16
shornedoes anyone know the official word on
shornestekern: thanks, I assume twiki was where they were collected before?  and the discussed on the mailing list?06:21
shorneI mean mediawiki06:23
olofkshorne: We contacted them yesterday, but haven't heard back06:29
shorneolofk: anything in particular on the twiki worth saving? There are good copied on wayback machine ( including mediawiki source06:39
shorneI think can use some work, but not sure keeping all of the wiki content is best06:40
olofkshorne: We've been writing a lot of stuff on that wiki. Not sure of anything specific we want to save. We've been meaning to migrate the useful stuff to openrisc.io06:42
olofkBut as you say, it's not worth keeping the whole wiki. Lots of crap there06:42
shorneolofk: yeah, I think the rewrite onto can move most of the content, but just not a full copy06:52
shornei.e. that wiki has at least 2 toolchain build instructions06:52
shorneI think I have seen a 3rd06:52 has one06:53
shorneinterstingly part of my orconf 2016 talk is about the state of documentation, one of the points was what to do with opencores.org06:54
shornebut... maybe that can be scratched now :)06:54
ZipCPUCan it?  I (and others) have still been looking for a suitable replacement site.06:55
shorneZipCPU: I am just saying if its gone, we dont have control.  We need to replace it06:58
shorneWe can add content to here
shorneto get on openrisc.io06:58
shorneZipCPU: I understand you used the forum quite heavily, what other things were most important to you?06:59
ZipCPUI have enjoyed posting cores on the site.07:00
SMDhomeI could provide a storage/server if you need one btw07:00
ZipCPUI look forward to posting cores on a new site.07:00
ZipCPUI have enjoyed posting on other forums, digilent's primarily, and pointing people towards the open cores.07:00
ZipCPUThe information I have on the site, though, ... I can re-create all of it if need be.07:01
olofkWe've seen the writing on the wall for a long time, and that was why getting up an opencores replacement has been high on our list of priorities07:02
olofkThe ambition is of course not to be a 1:1 replacement07:02
olofkcode hosting is best left to github, gitlab, sourceforge or whatever07:03
olofkGeneral forum questions will probably end up on stack overflow and friends, while OpenRISC-specific questions go to the mailing list07:03
olofkWe are open to new mailing lists too if people want them07:03
ZipCPUBut what about "core" hosting?  By that I mean, having a page outlining/advertising each core?07:04
ZipCPUAllowing users to "search" for appropriate cores for what they need07:04
olofkDon't want to say too much right now, as I haven't been part of the development of the new site, but we will provide an update at orconf07:05
olofkSo, we have some things planned, and we also want to know what the users want07:06
olofkAs we're aiming to build something useful07:06
olofkNot just what WE think is useful :)07:06
ZipCPUAll good goals.07:08
ZipCPUOne problem with OC to mention has been core support.  Sadly, once someone publishes a core to the site, as has happened with many cores, if the someone vanishes ... who answers the mail on his cores?07:09
ZipCPUIt's been sad to see/have forums, to hear questions of those wishing to use particular cores,07:10
ZipCPUonly to hear those questions echo in an empty forum chamber.07:10
shorneZipCPU: why not use freecores? http://freecores.github.io07:16
ZipCPUHmm ... maybe 'cause I'm not familiar with it?  ;)07:17
shorneI think its managed by one of us, blueCmd
* ZipCPU is looking up http://freecores.github.io07:17
blueCmd"managed" :P07:18
shorneI found it when I was looking to update one of the cores on opencores, it seems they took everything from opencores and stuck it under freecores on github07:18
blueCmdbut yes, ^ is what I did07:18
blueCmda gigantic for loop of all the cores on OC, svn -> git everything that could be saved and upload to github07:18
ZipCPUHmm ... well, that's a good start ...07:19
blueCmdsome repositories are sadly gone, as the underlying disk appears to have errors (don't recall exactly the error, but it was pretty clear it was permanent)07:19
blueCmdZipCPU: it was at a time where OC was down more than it was up, and it broke a lot of stuff. and we were afraid of losing everything07:20
shorneblueCmd: any idea how ZipCPU could get more cores on freecores?07:20
shorneor would that be the best thing to do?07:20
blueCmdhe/she wants to upload new ones?07:20
blueCmdI'd be happy to add people to the organization07:21
ZipCPUWell ... I would like a place to store my cores, but ... it'd be nice to have some more search options.07:21
ZipCPUOC allows you to search on things like: has specification, wishbone compliant, etc.07:22
ZipCPUWhat state is the project in and so forth.07:22
blueCmdZipCPU: feel free to extract that metadata and add it to freecores if you feel like it07:22
blueCmdwould certainly be useful07:23
ZipCPUIt would also be nice to have a metadata field indicating what I/O the core was compliant with.07:24
ZipCPUExample: JTAG, SPI, UART, DDR/DDR2/DDR3, etc.07:24
ZipCPUDevices could be compliant with multiple I/O standards--for example, and SD card controller might be compatible with both SDIO and SPI.07:24
blueCmdwould be pretty cool to have a .yaml or .json or something about the state of the core in every repository07:24
olofkblueCmd: Or a .core file :)07:25
olofkAdding tags like this has been on my TODO list for quite a while07:25
ZipCPUSure, another metadata tag: has '.core' file!07:25
blueCmdolofk: sure. what format is a .core file?07:25
olofkZipCPU: I was thinking the other way around, like adding the tags to the .core files :)07:26
ZipCPUThat would probably be a big help to you, olofk, as it would encourage core developers to build said files.07:26
blueCmdolofk: though it might be better to have metadata reference a .core, than embedd everything to be a mix of human readable things and machine readable things07:26
ZipCPUolofk: You mean ... the same type of metadata tags I was just refering to?07:26
blueCmdbut I'm just a guy on the internet with opinions07:26
olofkblueCmd: It's more or less .ini style. Been thinking of switching to yaml in the future07:26
olofkZipCPU: Yes. Exactly07:26
olofkTo let you filter out all wb compatible cores, or all written in verilog, or whatever07:27
olofkI've just been waiting with adding it until there is something around that can use the tags07:27
ZipCPUHave you defined the tags?07:27
blueCmdolofk: mind linking me the most complex .core file you have to date?07:27
olofkBut hopefully things will become clearer on October 8 :)07:27
shorneCurently it seems all the metadata for the freecores page is based just on what is extracted from the github project (i.e. language, last update, project description)07:28
olofkblueCmd: Just need to read up on find with -exec :)07:28
ZipCPUfind . -type f -name "*.core" -exec grep -H keystring \{\} \;07:29
blueCmdolofk: I never remember :P07:29
blueCmdolofk: find . -blablalba -print0 | xargs -0 wc -l07:29
blueCmdI find that syntax easier07:29
olofkI tend to fall back to for i in `find bla bla`; do stuff $i;done07:29
blueCmdanyway, having the metadata is better than not having the metadata - so use whatever format you feel like07:30
ZipCPUBut ... it needs to be a machine readable (and particularly web server readable) format.07:30
olofkblueCmd: This one is pretty long at least
shornecores sounds good to me, would be nice if we could automatically build them based on a template. And pull any metadata from opencores.org07:31
olofkI've already switched most of the cores in orpsoc-cores that were fetched from opencores to the freecores repo07:31
olofkAnd for the ones I made modifications too, I put them in my own repo07:31
olofkThat's a good thing with github. It's easy to just fork dead projects and keep working07:32
olofkThat never worked for opencores07:32
olofkIf anyone wants to help out on the web development side, please contact us. We could use some more hands07:32
ZipCPUAnother necessary metadata tag: license.07:33
ZipCPUCould be GPL, LGPL, CC, Mozilla, BSD, etc ...07:33
olofkZipCPU: HAha: Also on my TODO :)07:35
olofkI have a license and tags branch in FuseSoC :)07:35
ZipCPUolofk: You mentiond YAML or JSON as a replacement for your INI format for the .core file.07:35
ZipCPUIs there something that cannot be done in the current format?07:36
shorneolofk: possibly for the web frontend whenever orpsoc-cores is updates we could generate some manifest.json07:36
ZipCPUI mean, are you bumping up against some kind of limitation?07:36
shorneby scanning all the .cores07:36
shornethen that could be used as the db for freecores search07:36
olofkZipCPU: Not really. I think it's quite handy, but yaml would give you some additional structure for free07:36
olofkLike lists07:36
olofkI do lists now with [keyword name] , like [parameter one_param] [parameter other_param]07:37
blueCmdolofk: not too bad, good job :)07:37
blueCmdfiles like that quite often end up huuuuge07:38
olofkThe thing is that already from the beginning, I specified that the file had to start with CAPI=107:38
olofkThis was so that we could change to a completely different format eventually and only having to scan the first line to check07:38
olofkSo CAPI 2 could as well be yaml07:39
ZipCPUolofk: How hard would it be to build a Java App that built a .core file?07:39
olofkBut there are far more important priorities07:39
olofkZipCPU: Not to hard, depending on the complexity of course07:39
ZipCPUPerhaps you could plug in a current CAPI=1 file, and it would spit out a CAPI=2 ...07:40
olofkShouldn't be a problem07:40
ZipCPUPerhaps you could just fill in a form of some type, and it would spit out a template for a new core with many of the parts and pieces filled in.07:40
olofkBut FuseSoC needs to be prepared for a switch07:40
olofkI want it to stay backwards-compatible, so I need to add checks to see which tags are valid in the different APIs and so on07:41
olofkI've been thinking about .core generators too07:41
olofkAnd GUIs07:42
olofkSo many things. So little time :(07:42
blueCmdolofk: well, the thing with yaml is that the first line needs to be '----' for it to be yaml07:49
blueCmdnot all parsers enforce that, but that's the standard07:49
olofkblueCmd: Yes, I know. The CAPI=1 line is illegal for ini files too07:51
olofkSo consider it a frame07:51
blueCmdah hm ok07:51
olofkI know it's bad because it breks parsers that way, but I did it to make the payload independent07:52
olofkPros and cons :)07:52
ZipCPUolofk: If I were to try to build an automated/GUI fuseSoC core generator, 2) would you be willing to help me get the format right, and 2) be willing to test/try it?  (I'd still need to find somewhere/someone to host it ...)08:09
olofkSure. Happy to08:10
olofkAlso, FuseSoC was built with the intention to be used as a (Python) library in addition to being a stand-alone tool08:11
olofkSo if you're planning to do it in Python, you could easily integrate FuseSoC into your tool08:12
olofkBut if not, the core files are meant to be tool-agnostic, so any language should be able to read/write the .core files08:12
ZipCPUHmm ... I was thinking of a java app, so it could run within a web page and easily port from one machine to another.08:12
ZipCPUThe problem, of course, being that java apps can't search your folders for HDL files ...08:13
ZipCPU(Unless they changed the standard and the sandbox since I last looked ...)08:13
ZipCPUblueCmd: Yes, I am looking for a place to host my cores.  It looks like the freecores site is a subset of github, no?  Would there be any difference between getting a github site to host my cores, and using the freecores section of github?09:39
ZipCPUThis may be a question for all: Should the purpose of whatever replaces open cores be to link to valid core .core files?  Either on github or ... wherever they exist on the web?09:40
shorneZipCPU: I would say that the nice thing about freecores and opencores is that they allow you to search all in one place09:56
blueCmdZipCPU: it doesn't matter, you can host it on your own github account - but as shorne said it will not be cared for (it's barely cared for now, but if it is in the future)09:57
shorneThat way everyone can search09:57
ZipCPUblueCmd: What do you mean by "it will not be cared for"?  Did I miss that comment above somewhere?10:01
blueCmdZipCPU: I mean, we have no way of for example updating your core if you were to get hit by a bus10:10
blueCmdZipCPU: or if olofk wants to update his .core format and go over all .core files he wouldn't know your core existed10:11
blueCmdand stuff like that10:11
ZipCPUGot it.  Thanks!10:12
olofkblueCmd: The core files in the FuseSoC standard library comes from many different places. They all contain pointers to where the code is stored, so that's not a problem15:06
olofkBut that of course only applies for cores that are already in the library. Finding new cores can be pretty hard without a good entry point15:06
olofkOpenCores was just that. A good entry point15:06
olofkAnd this is something we want to provide now instead15:07
ZipCPU|Laptopolofk: If you have a moment, I tried my hand building my first core file:15:53
ZipCPU|LaptopHmm ... never mind ... looks like I messed up some naming.  Give me a moment and I'll get back to you.15:54
ZipCPU|LaptopHere it is:
olofkCan't access it16:16
olofkFound it16:17
olofkReview follows16:17
olofk1. No need for "" around the description16:17
olofk2. Using the verilog section is the old way of doing .core files. It's still available for backwards compatibility, but please use filesets instead16:18
olofk[fileset rtl]16:19
olofkfiles = rtl/wbm2axisp.v16:19
olofkfile_type = verilogSource16:19
olofk3. cachable = true is the default, so no need to specify that16:19
olofkAlso, if you want to store the core file in the repo, there is no need to add the provider section there. If you want to submit it to the FuseSoC standard core library however, you will need this section16:20
olofkA bit more context about the last thing I said;16:22
olofkThere are two ways to access the contents of a core16:22
olofkIf there is a [provider] section, FuseSoC will use that to download the code into its cache16:23
olofkIf the cache is empty, I should say16:23
olofkIf there is no provider section, it will use the directory where the .core file was found as its base directory and use the files from there16:24
olofkSo for the standard core library, where we generally don't store any code, almost all .core files contain a provider section16:25
olofkFor some of my own cores that are under development, I store the .core file in the repo and FuseSoC will find the code there locally instead16:26
olofkIf I only could take the time to document all this some time :/16:27
olofkOh well. Good night16:27
ZipCPU|LaptopOk ... let me make some edits.16:27
ZipCPU|Laptopolofk: When you get up, I have a question about that provider section.  If I want to encourage people to incorporate it into a cores repository, shouldn't I fill it out?  Or is there a way to automatically import it that fills it in based upon where it was imported from?16:37
shorneZipCPU|Laptop: usually I think the repository will fill it out. and I think there is just one repository for cores now18:58
Hoolootwoor1ksim gets killed with SIGKILL (by itself??)  if it doesn't find xterm19:40
Hoolootwothere's no warning at all19:41
-!- hammond is now known as j2ee21:06
ZipCPU|LaptopI almost don't believe this: MicroBlaze has 4 I/O busses, two for peripherals and two cached, or split the other way, two for instructions and two for data.21:45
ZipCPU|LaptopAdding to their bloat: the peripheral busses cannot support any form of pipelining.  Hence a flash memory will always be notoriously slow, even if the flash can transfer one word (when pipelined) every 16 clocks.21:46
ZipCPU|LaptopThat's about 100ns per access on an Arty board when running the flash pipelined, whereas if microBlaze forces the flash to not be pipelined it would require a minimum of 225 ns per access--and probably more since the AXI bus is so bloated.21:48
ZipCPU|LaptopXilinx claims they can do one access every two clocks using their AXI interface, yet the WB can do one access per clock when pipelined.21:48
ZipCPU|LaptopXilinx MicroBlaze = CPU bloat.21:49
ZipCPU|LaptopWhat I don't get is, with a memory architecture that bloated, how they can claim to be able to consume < 1k LUTs?21:58
ZipCPU|LaptopCertainly, the only reason why their Dhrystone numbers are above 1.0 is because everything must be in a very well designed cache.21:58
-!- j2ee is now known as hammond23:28
--- Log closed Thu Sep 22 00:00:22 2016

Generated by 2.15.2 by Marius Gedminas - find it at!