"IP Cores" Support

[imphil]

Currently the hierarchy in librecores ends with "projects", which can be HW or SW or combined works.

We should introduce "IP Cores" (or named similarly) as a subhierarchy below a project (1:n).

Design idea:

• 1 directory == 1 core

Discovery options:

• automatically parse fusesoc core files (i.e. directory of .core/.system) file is "core directory"
• automatically parse ipxact files (similar to fusesoc above)
• let users manually cores by specifying the top-level core directory & additional metadata

Open Questions:

• does directory == core work for common projects out there? double check with some common projects.
• what metadata is minimally required/wanted per core?
• what data can we parse automatically in a generic way, what data is coming from fusesoc core file/ipxact files/..., and what needs to be entered manually?

[eliaskousk]

I believe that repos that have multiple core implementation might not have them in completely separate directories and might use "common" directories for sources that are used in multiple / all cores.

Your questions are valid and I don't have the answers or a generic solution to this though. Maybe we should find first some example multi-core repos and see what directories they contain?

If I had to choose though I would make the separation completely user controllable, i.e make no assumptions and instruct the user to specify what we need in a declarative format and then parse that.

[berndca]

I believe that there are valid reasons to have more than one IP in a repository. Multiple cores might share verification infrastructure or might be related in some way. I would always prefer to extract this type of information from the repository data since manual entries tend to get out of date. This information could perhaps be captured in an IPXACT catalog file in the root directory of the repository. For the purpose of indexing library elements it could be kept very simple (VLNV + description). I created a component index for the following repos:

• parallella/oh
• m-labs/milkymist
• VLSI-EDA/PoC
• alexforencich/verilog-ethernet
• dawsonjon/fpu

I'd be happy to create catalog files for any of them if the maintainer would like to add them to their repo.

[Paebbels]

As @eliaskousk wrote, we have a "common" directories for shared code (e.g. VHDL packages). Moreover, a directory represents a VHDL sub-namespace, so it contains multiple IP cores. Our IP cores can reference other IP cores which need to be integrated. E.g. a FIFO, or cache depends on our RAM abstraction layer OCRAM.

I don't believe that IP-XACT can describe our IP cores. So currently we won't provide such files for our library. I haven't found a dependency option yet nor have I found a way to handle multiple target devices, language versions of source files or different tool chains. And from a programmers standpoint it's a horrible XML standard, which does follow the W3C rules for good XML documents.

[berndca]

Creating an IPXACT catalog for PoC should be very straightforward. Have you had a chance to look at the standard? Do you have any specific concerns?

There are probably lots of people with valid criticism towards the IPXACT standard. However I would always prefer a widely used standard to a proprietary solution. Especially when dealing with a large number of users from different backgrounds and organizations. From a programming standpoint there is for instance the Python package xmltodict which does exactly what it's name implies, but would not even have to parse XML you could use your favorite templating approach for just writing out text. I don't think there is any need to worry about performance since most IPXACT files and certainly a catalog for PoC would be too small to create any perfornance issues.

[Paebbels]

@berndca I tried some tools to generate an IP-XACT file for one of PoC's simplest IP cores, but the tools couldn't handle it. I'm not worried about performance of XML; I' worried about supporting a standard that uses bad XML design. Maybe we should create a IP-XACT library for Python? (I know @olofk's ipyxact library, but this is no IP-XACT DOM implementation).

The standard is very long. Is there a step by step guide on how to write it by hand?

As far as I understand IP-XACT, it focuses on CPU buses and register interfaces. Only a handful of our IP cores have such an interface. As it looks to me, we would have to define dozens of new interfaces for our cores, until we could start to describe them with IP-XACT. Using for example AXI for every IP connection - like Xilinx does - is no good hardware design. Yes it might be fast for a stupid drag-and-drop designer, but it creates a huge overhead. I remember such a discussion years ago for normal software development. Such tools fall into the category of "Rapid Application Development" or RAD. Have we heard of them in the last 10 years? No!

But if you like, we could discuss how you would package our IP cores with IP-XACT.

[berndca]

IPXACT is not an all or nothing proposition. You can use as much or as little as you NEED. For the purpose of IP discovery in your library I'm proposing to create a catalog. You can find the outline of the catalog schema at the beginning of chapter 11, pg. 171 of the spec. For each block in you library you create one catalog item consisting of vendor: VLSI-EDA, library: PoC, name: version: and description: . Thats it, just 4 tags below catalog for each IP block.

[Paebbels]

I'll look into that chapter.

Edit: Lol, an IP-XACT document can have different root elements? And they didn't apply the database normalization rules... What a XML nightmare...

[olofk]

I agree that we can't put restrictions on one project or directory per repo as has been shown by others already.

I also think that many pieces of HDL code is a very bad fit for IP-XACT. I've actually started working on an article about this, that I've been meaning to publish soon. As @berndca says however, you can use as little as you need. In FuseSoC I only use the FileSets part, and I recently changed to use full VLNV naming for all cores (even though you can still leave out the Vendor and Library fields for backwards compatibility). My ipyxact library (https://github.com/olofk/ipyxact) was created to scratch an itch that I had, and it basically only implements the parts I'm using myself right now.

For LibreCores we will not enforce IP-XACT, but from my own point of view I would encourage people to create models where it makes sense to do so. As we are likely to treat FuseSoC .core files as first class citizens, the IP-XACT files can then be picked up from the .core files

[berndca]

I have created an example for a sample catalog with two blocks from the PoC library.

https://gist.github.com/berndca/8a9a95eb6a20a9b07e2c9a44045ec810