Hello all,

I am starting a new project today that I hope to turn into a paper or a poster for some eda conference next year. My main interest is in eda design for reuse tools and in particular with IP-Xact tools.

What I am going to do is convert a piece of legacy IP so that it can be used in a modern IP-Xact tool flow. I will keep a journal that documents every step to give examples of what type of problems are encountered when reusing IP and provide solutions that work for todays processes.

The IP that I am going to convert is the or1200 processor. It is over 10 years old and in need of a refresh and some maintenance. I have already done this before using the minsoc design but did not have the latest revisions of the cpu or a robust test suite to catch mistakes.

This time I am starting with a current copy of orpsocv2 and I will port any code changes over that are checked in during the course of this effort. I also have 25 simulations running that will provide some barebones assurance that nothing breaks as I refactor the design and split it into separate ip-xact components.

When finished I will have a up-to-date version of all the components in orpsocv2 that can be easily used by anyone with an IP-Xact editor. They will also each have a unit test suite that can test each component by itself rather than having to load the entire design. I will be able to demonstrate how easy it is to retarget the design to a different process or change the modules and configuration without a lot of messy work.

You are all invited to look over my shoulder and watch it change over the next year. I started today by creating a new library within the socgen project called "orp_soc". It contains a copy of the current orpsocv2 project and test suite for the generic design (no boards, I will add them later).

If you install the socgen project and all its needed tools then you can try it by typing:

socgen:> make workspace project=orp_soc
socgen:> make build_hw
socgen:> make run_sims

The 25 sims all pass and their log files match their run under orpsocv2.

If anyone knows of any code revisions that are NOT in the current orpsocv2 then please let me know.

Comments and suggestions are always welcome.


John Eaton

Hi John,

This sounds really interesting. I've been wanting to integrate more of the OpenCores IP into IP-XACT, and having some actual designs ported will be a huge help.

I would however prefer that you not use the orpsocv2 versions of the IP cores. I've been spending a lot of time lately to identify and separate the vital changes from the orpsoc forks back into the original versions. This is almost completed, and with orpsocv3 we can now use the upstream versions together with a few patches for most of the cores. Please take a look at git.opencores.org/orpsoc to see which patches that haven't been upstreamed yet.

Please let us know also where we can go to follow your efforts with this project


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

Olof,

Thanks for the info. I will keep my files in sync with your git repository.

John Eaton

Olof,

I have copied your designs over and my sims all run. I am seeing some icarus warnings on your top level

warning: Port 5 (active_wbm_adr_o) of arbiter expects 32 bits, got 1.Padding 31 high bits of the port.
warning: Port 31 (wbs_dat_i) of arbiter expects 32 bits, got 1.Padding 31 high bits of the port.


Also are you planning to add a i2c controller? If so then which one?

John Eaton

Hi John,



This is a work in progress. Many things are either not yet implemented or not properly tested. The warning that you see if fixed but not yet pushed, as I haven't settled on some architectural issues yet (that ironically would have been a bit easier to fix if I had IP-Xact support :) ). Still, I think I can push a quick fix for this particular problem later this week



My plan is to start with a smaller number of IP cores, probably the ones used right now, and extend it from there. An i2c controller will come at some time in the future, and I will probably begin by using this (http://opencores.org/project,i2c), which is the one that was copied into ORPSoCv2. The idea right now is to have enough IP cores to test simulation and make things run on the ordb2a board

One of the design decisions of orpsocv3 however is to make it easier to drop in any core you want by putting either a local copy or a Makefile that tells how to get it which patches to apply in a cores subdirectory

Which design did you use for testing, btw? For your purposes I would guess that the generic one should work best for you. It is meant to mimic the reference build in orpsocv2.

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

I am using the generic one.

That is one of the problems with your design. You have one generic and two board designs that all use different configurations of cores. You should have a generic version for each and every fpga board that you need to build. The goal is to check out the design with generic cores and then have a board design that reuses the generic design with target specific libraries for anything that cannot be synthesised. Doing it that way makes it alot easier to port a design to a new fpga target.

You probably want to start out with a generic design that has all possible cores together and working and then remove cores as needed to match each of your fpga targets. Then all you have to do is create a library for pads,srams, pll's that uses the fpgas instantances and you can support a different fpga board.


John Eaton

In my view, that is how I have done it. The cores directory is a pool of cores that each board build can get their cores from. Inside each board directory I have kept only the target-specific bits. (PLLs, pin mappings, target-specific IP cores)

The generic "board" (the name should really be changed, as it's rather a configuration or a system, and not always a physical board) could be changed to use all the available cores, but I have kept it small as there are many architectural issues that I want to work on first.

The three current ports are supposed to contain less code as I bundle things in common libraries (currently working on an improveed arbiter/mux structure).

For the top-level file, I ultimately like it to be autogenerated somehow, preferrably without having to invent a new configuration file format that no one else will use, and that is one of the main reasons that I am interested in IP-Xact.

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

It seems like we both understand that the top-level file (what you call orpsoc_pad.v, and what currently is orpsoc_top.v in orpsoc) needs to be unique for each target, and that it should instantiate target-specific things, such as PLLs and buffers

I'm not sure what you want to put in the sub top orpsoc_top.v however. Could you elaborate a bit on that. As I see it, you would need to edit both orpsoc_pad.v and orpsoc_top.v when you add or remove a core, and both files would need to be unique for each target. On the other hand, there is a good reason to separate things that way, as you could just instantiate the sub top in simulations and avoid simulating with the target-specific parts.

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

The sub orpsoc_top.v contains what you currently have minus the clock generator and jtag. Those are target specific. Right now you have a orpsoc_top.v in board/ordb2a that has ethernet, usb, i2c, spi etc and a different orpsoc_top.v in board/generic that doesn't have those cores. I want to be able to set ETH0 in my generic board configuration file to add ethernet to the generic board. I don't want to have to reedit the entire orpsoc_top.v file and copy/paste code from the other board files. Create one orpsoc_top.v for all the boards and put all the target specific stuff in orpsoc_pad.v.

If you want to add a new core for a new board then you only have one file to change and once it is in then all of your existing boards can add that core simply by changing their configuration file.



John Eaton

I see what you mean now, but I don't think I will implement it like that for ORPSoCv3. There are a few reasons for that
* Ultimately, I want orpsoc_top (with generic cores and target-specific stuff) to be auto generated, so there won't be a copy/paste problem
* I believe that orpsoc_top would become really messy if I want support for three ethernet macs and eight spi blocks and have to support every permutation of memory controllers and things like that
* It will make it more complicated for people who want to add a core that is not "officially" supported by ORPSoC

There is still some experimenting with orpsocv3 however, so this feedback is most welcome

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

Hi,
I'm painfully familiar with IP-XACT (I generated IP-XACT files for all the opencores in 2008, and found lots of bugs in IP-XACT). I've been wanting to do an update, but get IP-XACT plus opeencores plus UVM working together, so that the the opencores files are using the interfaces/portnames the IP-XACT people defined for standard interfaces, and then write some UVM testbenches to do testing equivalent to what the current simulations do.

That should give people an outstanding before/after example, for transitioning over to IPXACT/UVM.
Plus, of course, it'll make it even more attractive to use opencores.

Erik

One of the problems with IP-Xact is that it really doesn't work. There is a lot in the standard that is good and useful but then it throws in something that is really really bad. For example one of the cardinal rules in design for reuse is that you NEVER make copies of data in your database. Each item is stored in one and only one location. Everyone who needs to access that item will get it from that location.

If you copy data then you run the risk that the copies will get out of sync during the development process so you need a tool that detects this so that designers can decide if the changes need to be made in all the other copies. This is a big mess to deal with during product development and the reason why we should all use the master copy of the or1200 in oour soc's instead of simply copying the bits.

IP-Xact has some areas that require copies of data that reside in other places. This will complicate what could have been some nice simple tools.

IP-Xact is also presented as a all-or-nothing standard. Jtag (IEEE-1149) on the other hand defines a set of basic must have features as IEEE1149.0. Extra functions are added in their own .1 .2 etc layers.

This means that you can easily get started with jtag without spending 80% of your time and effort working on the 20% of the features that are rarely used. IP-Xact needs to define a similar minimal subset.

IP-Xact is also missing some critical functions. For example if you have a design that connects a bus of adhoc signals between two instances there is no way to declare the size and indexes of the wire. You can do it if the bus is ported up and out of the design or if you use bus definitions but not for internal adhoc busses.

I have been using IP-Xact but only a minimal subset and I throw in new fields or drop defined ones as I see fit. I do have a tool set that will process my files but I run into problems when sharing files with other tool flows.

IP-Xact is close to what we need to make our IP reusable but it is not quite there. Using it with my toolset has greatly simplified the design process and removed a lot of error prone manual labor so I will continue to develop with it.

John Eaton