Hi

Before I get to the proposed core structure, I need to give some background first.

We have developed a cross-vendor firmware design management environment in our team. It integrates and sync's with many design environments (Sigasi, Mentor Graphics HDL Author etc) and takes care of the full implementation processes for multiple back-ends (Xilinx, Altera, Plunify etc.).

The power of this tool lies in something we call "file association databases". These databases are simple XML files containing details about file types used in the firmware world. The idea is that they can evolve over time through knowledge added to them by experts in the field.

The knowledge contained in these databases allows us to perform advanced operations on the files in a design. It also enforces directory structures and along with this it knows what needs to end up in version controlled repositories and what needs to stay out. This is very powerful, for example it allows you to do version control and package cores consistently across OpenCores.

At present a ready to use HDL Design database covers Xilinx, Altera and Mentor Graphics tools. I suspect for OpenCores a dedicated "OpenCores" database should be created to fit the needs of cores hosted on OpenCores.

A detailed blog post about the file association database architecture can be found here: http://scineric.csir.co.za/?p=1083 and the tool itself has a blog here http://scineric.csir.co.za.

At the moment we are not sure if we are going to open source it, or if we are going to take a different route. However we do believe that it can be very useful to make sure that all cores are formatted in the same way across all cores on OpenCores.

What do you think about such an approach?

Thanks,
Jaco

I would view any requirement other than a simple "please add this new file into your project" as a non starter. You are lucky if you can even find a project's maintainer and most of them will not want to change or move anything that might impact their user base. If you build a better mouse trap the world will eventually beat a path to your door but starting out will still require alot of salesmanship.

You might consider creating your own project containing your tools and databases for other opencores projects so that their users can also download your project to use tools that help them on their project.

You could start out on something like openrisc since that has alot of users and is actively maintained.

Create your database file and get it added to a repository along with a simple tool that does something usefull. By simple I mean perl script. By usefull I mean "Build your SOC and this script will send your data to PLUNIFY , synthesys, route and return a bit file. Once users discover that your tool lets them use any fpga board without having to muck around installing fpga tools then you will start to build a user base.

Then you can expand and show how your tool can also do things like download and install the or32-elf tool chain and compile firmare for their boards.

Keep the free tools simple and usefull so you can still offer a full featured gui based tool for $$$.

I do see the value in your proposal but it will still be a hard sell to get projects to make any changes.


John Eaton

I agree with John here. It would be nice to solve the issue of core management, but there are about as many proposals as there are users right now. Parts of IP-Xact was going to solve this, but the standard has grown so insanely complex that, at least I, found little benefit compared to the work needed to implement support.

I'm doing something similar in orpsocv3 with an ini-file based format, but I reckon that it will be difficult to force projects to use as specified structure, so I'm taking my inspiration from Linux distributions (Gentoo's ebuilds are the largest inspiration right now) instead. By this I mean that I'm leaving the upstream core intact, but add core description files and any patches in orpsoc itself. This of course has other problems, but for the scope right now it works fine.

Anyway, I wish you luck with your project, and hope to see a good solution to core management in the near future.

--
Olof Kindgren
______________________________________________
ORSoC
Website: www.orsoc.se
Email: olof.kindgren@orsoc.se
______________________________________________
FPGA, ASIC, DSP - embedded SoC design

My current method is if your IP doesn't fit in my structure then I will create a wrapper that instantiates your ip and that deals with all the issues. I have never been comfortable with patches. Hardware design is more complex than software and you can do alot of things in software that doesn't work for us. One example is generated files. A software designer can mask out all *.obj files from RCS checkin because they are all generated. A hardware designer doesn't know if a *.v verilog file was handcrafted and must be checked in or machine created from a fsm or register tool. Patching files may work fine in the software world but they make me nervous.


I am still amazed at how many designers will run their design flows inside of their RCS repositry and then rely on masking to not check in generated files. Masking out files in an RCS repository is pure EVIL! Have you seen some of the build scripts that designers use? Makefiles calling perl scripts calling shell scripts piping results into files that are then edited with SED. These things are a real house of cards and their behaviour can change based on the existance and time stamp of files in the repository. So you have this feature where you can add new files and your rcs software will deny that anything has changed and you don't see how this could possibly be a problem?

You should use the lndir command to create workareas from your repositories. That eliminates a lot of your rcs usage issues. How much time do you spend making sure that "make clean" works? I do a rm -r * and then rerun lndir. Works great and my repositories are never touched.

One thing that is certain is that you are not allowed to touch any of your source IP repositories. If it is that screwed up and the maintainer doesn't fix it then your only option is to branch it into a new repository and assume engineering responsibility for all of it.



John Eaton

Thanks for the responses. I have limited access to internet at the moment as I am travelling thus my responses might be lagging a bit.

John, thanks for the feedback. I have attended the FPL conference over the last three days and we actually exhibited our tool. It was interesting to see people's reactions and it is exactly as you say. At first people don't really pay too much attention but every person that we actually provided a personal demo to had a "wow" moment and was really impressed and saw the value in the tool. I think people in our industry are very set in their ways and the challenge will definitely be to get them to realize that the tool CAN and WILL help them. I like the idea of actually adding our ready to use database to a repository somewhere, but I will have to chew a bit on where and how exactly.

Olof, thanks for your feedback as well. I'm glad you mentioned IP-XACT and I did not mention it in my original post to keep it simple. We initially created out own schema to manage everything and recently moved to IP-XACT. Thus, our tool packages a design as an IP-XACT component without any effort. Many people won't appreciate or realize it at the moment, but those who know about IP-XACT will immediately see the value in this. It works really well, for example I've been testing our tool on the Xilinx IP repository and we are able to open and edit any core in the Xilinx repository in the tool. I attended a talk on IP-XACT today and I'm quite impressed by the standard (although we use only parts of it) and I definitely believe its the future. We are trying to make packaging of a design and its metadata in IP-XACT a process where the user does not even need to know that its happening. In this way the number of designs actually packed in this standard will increase gradually over time (hopefully fast). I can go on about this quite a bit, but I think you should check out the tool, it really is quite powerful in the way that it handles the definition of what is generated and what not, as well as the structure of a design and as a bonus it packages everything in IP-XACT without you thinking about it.

Thanks again for the feedback, I believe we are a step closer to having a good core management solution that can actually fit into the user's environment through our customized database approach.

Cheers,
Jaco

Hi John & Olof

Thanks for your responses and feedback. Please find my comments below.



Thanks for the feedback John. Over the last three days I attended FPL and it is as you say, people are pretty set in their ways and we just saw it again. We actually exhibited our tool and many people did not pay too much attention, however the ones that we spent time with and demo'ed the tool to all had a "wow" moment and were really impressed by it. Thus, as you say the trick is to get people to understand how it CAN and WILL help them. If we can at least make new users switch I think we are on the right path.



Sounds like a good idea. I will have to chew a bit on it first since we already have our blog with a download area etc. However I will think of ways to get OpenCores users to realize its there.



Thanks for the suggestion I will definitely look into it.



Hi Olof. I'm glad that you've mentioned IP-XACT. I did not want to mention it in my initial post to keep things simple. We initially created out own schema to define and store the design and its metadata, but recently converted everything to IP-XACT. I agree that the current problem with IP-XACT is that its way too complex to package your design by yourself. We tried to address this in our tool and it packages everything in IP-XACT for you without having to thinking about it. Most people won't realize or appreciate it, but those who do will realize that its very powerfull. We tested the tool using many exiting cores pacakged as IP-XACT components (for example we can open and edit any core in the Xilinx IP repository). I can go on about this topic for a long time, but I think you should rather check out the tool to see how easy it is to package a design in IP-XACT using it (you can for example create an IP-XACT component from the contents of a folder and everything underneath it using about 3 mouse clicks or so).



Thanks. I do believe that we've taken the first step to a proper solution. IP-XACT does not solve all the problems, but we've added a bunch of vendor extensions to it that helps you to classify files properly (for example generated or not generated) and that properly defines the structure of a design in a way that can easily be updated and shared. Hopefully we will see the start of a migration of users that use it which will in turn trigger the migration to a standarized way to package cores using IP-XACT.

Cheers,
Jaco