| --- Log opened Wed Sep 21 00:00:21 2016 | ||
| shorne | olofk: 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 |
|---|---|---|
| shorne | does anyone know the official word on opencores.org? | 06:16 |
| shorne | stekern: thanks, I assume opencore.org twiki was where they were collected before? and the discussed on the mailing list? | 06:21 |
| shorne | I mean mediawiki | 06:23 |
| stekern | yes | 06:25 |
| olofk | shorne: We contacted them yesterday, but haven't heard back | 06:29 |
| shorne | olofk: anything in particular on the twiki worth saving? There are good copied on wayback machine (https://web.archive.org/) including mediawiki source | 06:39 |
| shorne | I think openrisc.io can use some work, but not sure keeping all of the wiki content is best | 06:40 |
| olofk | shorne: 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.io | 06:42 |
| olofk | But as you say, it's not worth keeping the whole wiki. Lots of crap there | 06:42 |
| shorne | olofk: yeah, I think the rewrite onto openrisc.io can move most of the content, but just not a full copy | 06:52 |
| shorne | i.e. that wiki has at least 2 toolchain build instructions | 06:52 |
| shorne | I think I have seen a 3rd | 06:52 |
| shorne | openrisc.io has one | 06:53 |
| shorne | interstingly part of my orconf 2016 talk is about the state of documentation, one of the points was what to do with opencores.org | 06:54 |
| shorne | but... maybe that can be scratched now :) | 06:54 |
| ZipCPU | Can it? I (and others) have still been looking for a suitable replacement site. | 06:55 |
| shorne | ZipCPU: I am just saying if its gone, we dont have control. We need to replace it | 06:58 |
| shorne | We can add content to here https://github.com/openrisc/openrisc.github.io | 06:58 |
| shorne | to get on openrisc.io | 06:58 |
| shorne | ZipCPU: I understand you used the forum quite heavily, what other things were most important to you? | 06:59 |
| ZipCPU | I have enjoyed posting cores on the site. | 07:00 |
| SMDhome | I could provide a storage/server if you need one btw | 07:00 |
| ZipCPU | I look forward to posting cores on a new site. | 07:00 |
| ZipCPU | I have enjoyed posting on other forums, digilent's primarily, and pointing people towards the open cores. | 07:00 |
| ZipCPU | The information I have on the site, though, ... I can re-create all of it if need be. | 07:01 |
| olofk | We'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 priorities | 07:02 |
| olofk | The ambition is of course not to be a 1:1 replacement | 07:02 |
| olofk | code hosting is best left to github, gitlab, sourceforge or whatever | 07:03 |
| olofk | General forum questions will probably end up on stack overflow and friends, while OpenRISC-specific questions go to the mailing list | 07:03 |
| olofk | We are open to new mailing lists too if people want them | 07:03 |
| ZipCPU | But what about "core" hosting? By that I mean, having a page outlining/advertising each core? | 07:04 |
| ZipCPU | Allowing users to "search" for appropriate cores for what they need | 07:04 |
| olofk | Don'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 orconf | 07:05 |
| olofk | So, we have some things planned, and we also want to know what the users want | 07:06 |
| olofk | As we're aiming to build something useful | 07:06 |
| olofk | Not just what WE think is useful :) | 07:06 |
| ZipCPU | All good goals. | 07:08 |
| ZipCPU | One 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 |
| ZipCPU | It's been sad to see/have forums, to hear questions of those wishing to use particular cores, | 07:10 |
| ZipCPU | only to hear those questions echo in an empty forum chamber. | 07:10 |
| shorne | ZipCPU: why not use freecores? http://freecores.github.io | 07:16 |
| ZipCPU | Hmm ... maybe 'cause I'm not familiar with it? ;) | 07:17 |
| shorne | I think its managed by one of us, blueCmd https://github.com/freecores | 07:17 |
| * ZipCPU is looking up http://freecores.github.io | 07:17 | |
| blueCmd | "managed" :P | 07:18 |
| shorne | I 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 github | 07:18 |
| blueCmd | but yes, ^ is what I did | 07:18 |
| blueCmd | a gigantic for loop of all the cores on OC, svn -> git everything that could be saved and upload to github | 07:18 |
| ZipCPU | Hmm ... well, that's a good start ... | 07:19 |
| blueCmd | some 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 |
| blueCmd | ZipCPU: 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 everything | 07:20 |
| shorne | blueCmd: any idea how ZipCPU could get more cores on freecores? | 07:20 |
| shorne | or would that be the best thing to do? | 07:20 |
| blueCmd | he/she wants to upload new ones? | 07:20 |
| blueCmd | I'd be happy to add people to the organization | 07:21 |
| ZipCPU | Well ... I would like a place to store my cores, but ... it'd be nice to have some more search options. | 07:21 |
| ZipCPU | OC allows you to search on things like: has specification, wishbone compliant, etc. | 07:22 |
| ZipCPU | What state is the project in and so forth. | 07:22 |
| blueCmd | ZipCPU: feel free to extract that metadata and add it to freecores if you feel like it | 07:22 |
| blueCmd | would certainly be useful | 07:23 |
| ZipCPU | It would also be nice to have a metadata field indicating what I/O the core was compliant with. | 07:24 |
| ZipCPU | Example: JTAG, SPI, UART, DDR/DDR2/DDR3, etc. | 07:24 |
| ZipCPU | Devices could be compliant with multiple I/O standards--for example, and SD card controller might be compatible with both SDIO and SPI. | 07:24 |
| blueCmd | would be pretty cool to have a .yaml or .json or something about the state of the core in every repository | 07:24 |
| olofk | blueCmd: Or a .core file :) | 07:25 |
| olofk | Adding tags like this has been on my TODO list for quite a while | 07:25 |
| ZipCPU | Sure, another metadata tag: has '.core' file! | 07:25 |
| blueCmd | olofk: sure. what format is a .core file? | 07:25 |
| olofk | ZipCPU: I was thinking the other way around, like adding the tags to the .core files :) | 07:26 |
| ZipCPU | That would probably be a big help to you, olofk, as it would encourage core developers to build said files. | 07:26 |
| blueCmd | olofk: 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 things | 07:26 |
| ZipCPU | olofk: You mean ... the same type of metadata tags I was just refering to? | 07:26 |
| blueCmd | but I'm just a guy on the internet with opinions | 07:26 |
| olofk | blueCmd: It's more or less .ini style. Been thinking of switching to yaml in the future | 07:26 |
| olofk | ZipCPU: Yes. Exactly | 07:26 |
| olofk | To let you filter out all wb compatible cores, or all written in verilog, or whatever | 07:27 |
| olofk | I've just been waiting with adding it until there is something around that can use the tags | 07:27 |
| ZipCPU | Have you defined the tags? | 07:27 |
| blueCmd | olofk: mind linking me the most complex .core file you have to date? | 07:27 |
| olofk | But hopefully things will become clearer on October 8 :) | 07:27 |
| shorne | Curently 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 |
| olofk | blueCmd: Just need to read up on find with -exec :) | 07:28 |
| ZipCPU | find . -type f -name "*.core" -exec grep -H keystring \{\} \; | 07:29 |
| blueCmd | olofk: I never remember :P | 07:29 |
| blueCmd | olofk: find . -blablalba -print0 | xargs -0 wc -l | 07:29 |
| blueCmd | I find that syntax easier | 07:29 |
| olofk | I tend to fall back to for i in `find bla bla`; do stuff $i;done | 07:29 |
| blueCmd | anyway, having the metadata is better than not having the metadata - so use whatever format you feel like | 07:30 |
| ZipCPU | But ... it needs to be a machine readable (and particularly web server readable) format. | 07:30 |
| olofk | blueCmd: This one is pretty long at least https://github.com/openrisc/orpsoc-cores/blob/master/cores/nyuzi/nyuzi.core | 07:31 |
| shorne | cores sounds good to me, would be nice if we could automatically build them based on a template. And pull any metadata from opencores.org | 07:31 |
| olofk | I've already switched most of the cores in orpsoc-cores that were fetched from opencores to the freecores repo | 07:31 |
| olofk | And for the ones I made modifications too, I put them in my own repo | 07:31 |
| olofk | That's a good thing with github. It's easy to just fork dead projects and keep working | 07:32 |
| olofk | That never worked for opencores | 07:32 |
| olofk | If anyone wants to help out on the web development side, please contact us. We could use some more hands | 07:32 |
| ZipCPU | Another necessary metadata tag: license. | 07:33 |
| ZipCPU | Could be GPL, LGPL, CC, Mozilla, BSD, etc ... | 07:33 |
| olofk | ZipCPU: HAha: Also on my TODO :) | 07:35 |
| olofk | I have a license and tags branch in FuseSoC :) | 07:35 |
| ZipCPU | olofk: You mentiond YAML or JSON as a replacement for your INI format for the .core file. | 07:35 |
| ZipCPU | Is there something that cannot be done in the current format? | 07:36 |
| shorne | olofk: possibly for the web frontend whenever orpsoc-cores is updates we could generate some manifest.json | 07:36 |
| ZipCPU | I mean, are you bumping up against some kind of limitation? | 07:36 |
| shorne | by scanning all the .cores | 07:36 |
| shorne | then that could be used as the db for freecores search | 07:36 |
| olofk | ZipCPU: Not really. I think it's quite handy, but yaml would give you some additional structure for free | 07:36 |
| olofk | Like lists | 07:36 |
| olofk | I do lists now with [keyword name] , like [parameter one_param] [parameter other_param] | 07:37 |
| blueCmd | olofk: not too bad, good job :) | 07:37 |
| blueCmd | files like that quite often end up huuuuge | 07:38 |
| olofk | The thing is that already from the beginning, I specified that the file had to start with CAPI=1 | 07:38 |
| olofk | This was so that we could change to a completely different format eventually and only having to scan the first line to check | 07:38 |
| olofk | So CAPI 2 could as well be yaml | 07:39 |
| ZipCPU | olofk: How hard would it be to build a Java App that built a .core file? | 07:39 |
| olofk | But there are far more important priorities | 07:39 |
| olofk | ZipCPU: Not to hard, depending on the complexity of course | 07:39 |
| ZipCPU | Perhaps you could plug in a current CAPI=1 file, and it would spit out a CAPI=2 ... | 07:40 |
| olofk | Shouldn't be a problem | 07:40 |
| ZipCPU | Perhaps 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 |
| olofk | But FuseSoC needs to be prepared for a switch | 07:40 |
| olofk | I want it to stay backwards-compatible, so I need to add checks to see which tags are valid in the different APIs and so on | 07:41 |
| olofk | I've been thinking about .core generators too | 07:41 |
| olofk | And GUIs | 07:42 |
| olofk | So many things. So little time :( | 07:42 |
| blueCmd | olofk: well, the thing with yaml is that the first line needs to be '----' for it to be yaml | 07:49 |
| blueCmd | not all parsers enforce that, but that's the standard | 07:49 |
| olofk | blueCmd: Yes, I know. The CAPI=1 line is illegal for ini files too | 07:51 |
| olofk | So consider it a frame | 07:51 |
| blueCmd | ah hm ok | 07:51 |
| olofk | I know it's bad because it breks parsers that way, but I did it to make the payload independent | 07:52 |
| olofk | Pros and cons :) | 07:52 |
| blueCmd | right | 07:53 |
| ZipCPU | olofk: 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 |
| ZipCPU | s/2)/1)/ | 08:09 |
| olofk | Sure. Happy to | 08:10 |
| olofk | Also, FuseSoC was built with the intention to be used as a (Python) library in addition to being a stand-alone tool | 08:11 |
| olofk | So if you're planning to do it in Python, you could easily integrate FuseSoC into your tool | 08:12 |
| olofk | But if not, the core files are meant to be tool-agnostic, so any language should be able to read/write the .core files | 08:12 |
| ZipCPU | Hmm ... 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 |
| ZipCPU | The 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 |
| ZipCPU | blueCmd: 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 |
| ZipCPU | This 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 |
| shorne | ZipCPU: I would say that the nice thing about freecores and opencores is that they allow you to search all in one place | 09:56 |
| blueCmd | ZipCPU: 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 |
| shorne | That way everyone can search | 09:57 |
| ZipCPU | blueCmd: What do you mean by "it will not be cared for"? Did I miss that comment above somewhere? | 10:01 |
| blueCmd | ZipCPU: I mean, we have no way of for example updating your core if you were to get hit by a bus | 10:10 |
| blueCmd | ZipCPU: or if olofk wants to update his .core format and go over all .core files he wouldn't know your core existed | 10:11 |
| blueCmd | and stuff like that | 10:11 |
| ZipCPU | Got it. Thanks! | 10:12 |
| olofk | blueCmd: 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 problem | 15:06 |
| olofk | But that of course only applies for cores that are already in the library. Finding new cores can be pretty hard without a good entry point | 15:06 |
| olofk | OpenCores was just that. A good entry point | 15:06 |
| olofk | And this is something we want to provide now instead | 15:07 |
| ZipCPU|Laptop | olofk: If you have a moment, I tried my hand building my first core file: | 15:53 |
| ZipCPU|Laptop | Hmm ... never mind ... looks like I messed up some naming. Give me a moment and I'll get back to you. | 15:54 |
| ZipCPU|Laptop | Here it is: https://github.com/ZipCPU/wb2axip/wb2axip.core | 16:02 |
| olofk | Can't access it | 16:16 |
| olofk | typo? | 16:16 |
| olofk | Found it | 16:17 |
| olofk | Review follows | 16:17 |
| olofk | 1. No need for "" around the description | 16:17 |
| olofk | 2. Using the verilog section is the old way of doing .core files. It's still available for backwards compatibility, but please use filesets instead | 16:18 |
| olofk | [fileset rtl] | 16:19 |
| olofk | files = rtl/wbm2axisp.v | 16:19 |
| olofk | file_type = verilogSource | 16:19 |
| olofk | 3. cachable = true is the default, so no need to specify that | 16:19 |
| olofk | Also, 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 section | 16:20 |
| olofk | A bit more context about the last thing I said; | 16:22 |
| olofk | There are two ways to access the contents of a core | 16:22 |
| olofk | If there is a [provider] section, FuseSoC will use that to download the code into its cache | 16:23 |
| olofk | If the cache is empty, I should say | 16:23 |
| olofk | If 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 there | 16:24 |
| olofk | So for the standard core library, where we generally don't store any code, almost all .core files contain a provider section | 16:25 |
| olofk | For 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 instead | 16:26 |
| olofk | If I only could take the time to document all this some time :/ | 16:27 |
| olofk | Oh well. Good night | 16:27 |
| ZipCPU|Laptop | Ok ... let me make some edits. | 16:27 |
| ZipCPU|Laptop | Thanks! | 16:27 |
| ZipCPU|Laptop | olofk: 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 |
| shorne | ZipCPU | 18:57 |
| shorne | ZipCPU|Laptop: usually I think the repository will fill it out. and I think there is just one repository for cores now | 18:58 |
| Hoolootwo | or1ksim gets killed with SIGKILL (by itself??) if it doesn't find xterm | 19:40 |
| Hoolootwo | there's no warning at all | 19:41 |
| -!- hammond is now known as j2ee | 21:06 | |
| ZipCPU|Laptop | I 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|Laptop | Adding 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|Laptop | That'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|Laptop | Xilinx 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|Laptop | Xilinx MicroBlaze = CPU bloat. | 21:49 |
| ZipCPU|Laptop | What 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|Laptop | Certainly, 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 hammond | 23:28 | |
| --- Log closed Thu Sep 22 00:00:22 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!