IP-Xact discussion

[Ouabache Designworks]

I would like to start a discussion on IP-Xact and how it should fit into Freecellera's plan
to conquer the world. Back around 2005 several companies joined together to form the spirit
consortium in order to create a packaging standard for IP. They started with some work that
Mentor had done and began to create the IP-Xact standard. They merged into Accellera and
released the IEEE 1685 standard in 2009 and again in 2014.

This standard was sorely needed in our industry. It tells the IP creators exactly how to
package their code for delivery to their customers. Customers no longer need to sift through
new code trying to figure out how to use it. That information is available in the IP-Xact files.
This enables us to do a "plug-an-play" tool set.

You can create a SOC builder tool so that once a piece of IP is entered into your design environment
that it can automatically add it into the library of available components. You can select it and
instantiate it into your IP with schematic capture. You will see a symbol with all ports and parameters
that you can configure and interconnect.

When you simulate your IP then the tool flows will build all subcomponents and load them into the tool.


The spirit consortium realized that nobody in this industry was ever going to modify any of their legacy
code in order to be compatible with some new standard so they designed IP-Xact to work with any way that
you package your IP. Put your files and directories anywhere you want and name them anything you like.
IP-Xact creates new files where you can tell the tools where you put things. You legacy code is untouched.

IP-Xact created a naming standard that allows any engineer to create a module with a name that is unique
through out the entire industry now and into the future. If you create names by picking something out of
thin air then there is a good chance that your user never see a naming collision. But the train wrecks
that name collisions can cause says that we need to do better than something than"probably works". We
need something that will work in all cases.

IP-Xact also restores the schematic capture data formats back to our industry. Back in the 70's and 80's ICs
were designed using schematic capture tools. Schematics of instantiated components were saved in .sch files.
A simply click would create a symbol for a schematic and save it in a .sym file that had a pointer to its
.sch file.

Large designs could break a schematic into multiple pages and the symbol into multiple symbols. You could not
do a PCB design today if you had to create one symbol with thousands of pins, you have to break it up.

We lost this in the 90's when HDL/Synthesys replaced schematic capture for design entry and these were all
replaced by a single .v or .vhdl file.

This was fine for the component designers who were doing leaf cells since they were treated like undividable
blocks. But this was not good for the architects that selected,configured and interconnected the leaf cells.
Having the multiple file structure gave them a lot of flexibility for reusing circuits in more than one design.

The IP-Xact component file is essentially a .sym file and the design file is a .sch file.



But IP-Xact does have its problems. When you create something like that you start out small with only the most
fundamental items that you need. You grow by adding new things on top of the existing structures until you get
a large full featured design. By this time all of your designers have a good understanding of what the design
does and how everything interacts.

Now try to teach this to a new engineer. The most fundamental structures are still there but when you studied
them they were alone on the page. Now they are buried amongst a dozen different items. It can be overwhelming.

That is why Jtag (IEEE 1149) did not release as a single standard. It is seven standards from 1149.1 to 1149.7.
The fundamentals were put in their on standard and released. Designers that only need the bare minimum can use
dot one and never have to deal with any of the more complex stuff because they were released in their own dot
level.

If you have a tool that claims to be IEEE 1685_2014 compatible then everyone expects that you support the entire
standard. If you release a tool to IEEE 1149.1 then you are making clear that there are sections that are not
supported. If IEEE 1149.4 is revised then you don't have to see how the changes affect your tool.


IP-Xact needs to be refactored into similar dot levels.

It also has problems because it has omitted allocating space for some needed data items. You need some data that
IP-Xact doesn't cover then you have to use a vendor extension. You should never have to use a VE for any data
if it is impossible to build the tool without it.


Finally IP-Xact is missing the "IP-Xact Design Handbook". Standards are pretty dull and really only tell you about
the "Whats". Every standard needs some author to write a handbook that also tells the "Whys and Hows". Look at
Ken Parkers Boundary Scan Handbook for a good example.


So what should Freecellera do? My suggestions:


1) Use IP-Xact for all tools that we create or support. If IP does not support IP-Xact then someone will need to create
   the IP-Xact files. You will need to dig out that information anyway to configure the tool but with IP-Xact it is only
   done once.


2) Refactor IP-Xact into appropriate dot levels and release that as documentation.


3) Write the  "IP-Xact Design Handbook". Somebody has to do it and we might as well make ourselves usefull.



Comments?


John Eaton

[Erik Jessen]

I agree with all 3.

Some other thoughts:

a) I would propose also to add some Freecelera-official extensions to cover places where IP-XACT didn't address things.

b) I'm sure that each of the huge companies has their own internal standard extensions; it would be wonderful if we could get them, so we could look them over.  I'm a great fan of copying good ideas - and hopefully one or more of those big companies would like the idea that we're working to make the standard more standard.

c) One thing IP-XACT does NOT have is clear definitions on some terms: e.g. something you can run through a unit-tester.  So a "unit-test-suite" of examples is needed to verify IP-XACT parsers.  I'm thinking of what they have for VHDL: you run the compatibility suite, and you should PASS every good example, and generate an error on every bad one.  I found a number of holes in the IP-XACT standard when I wrote such a suite.  We will likely need to do minor clarifications or alterations to the standard to close those holes.  Not a big deal - I would expect we could release a Python script to map from official IP-XACT to FREE-XACT (or whatever we wind up calling it).

d) how does one go about the partitioning problem?  I'm trying to think of partitioning that makes sense?  Pull out support for synthesis, FW, etc.?

Thanks for the long and well-written post!

Erik

--
You received this message because you are subscribed to the Google Groups "Freecellera" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freecellera...@googlegroups.com.
To post to this group, send email to freec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/freecellera/f67283a1-7663-4b96-99e7-ec6287a2ead4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bryan Murdock]

On Sat, Jan 2, 2016 at 7:27 PM, Ouabache Designworks <z3qm...@gmail.com> wrote:
>
> I would like to start a discussion on IP-Xact and how it should fit into
> Freecellera's plan
> to conquer the world. Back around 2005 several companies joined together to
> form the spirit
> consortium in order to create a packaging standard for IP. They started with
> some work that
> Mentor had done and began to create the IP-Xact standard. They merged into
> Accellera and
> released the IEEE 1685 standard in 2009 and again in 2014.

At the risk of showing my ignorance, I'm going to reply to this.

First of all, thanks for the background and history. I have come
across IP-XACT a few times, but only briefly. It was always presented
to me as a way to specify something bog-standard (usually registers)
in XML and then have a tool generate code (verilog, vhdl, c, c++,
etc.) and documentation (word, html, pdf, etc.) from that XML.
"Packaging IP" was never mentioned to me.

>
> This standard was sorely needed in our industry. It tells the IP creators
> exactly how to
> package their code for delivery to their customers.

It's not clear to me what packaging means here. I don't think you
mean like, should we use a zip file, or a tar.gz?

<aside>
Also, I think now is a good time for me to request that we, as the
Freecellera group, remove "IP" from our vocabulary. Look at the
explanations of IP-XACT from Acellera and from Wikipedia:

http://www.accellera.org/activities/working-groups/ip-xact

https://en.wikipedia.org/wiki/IP-XACT

Wikipedia avoids using the ambiguous term "IP" and it is a more clear
description of what IP-XACT is.

IP stand for Intellectual Property, which is a complete misnomer in
and of itself (see: http://www.gnu.org/philosophy/not-ipr.en.html),
but we in the chip design world don't even use that misnomer the same
way everyone else in the world uses it. Most everyone means "my
patented or copyrighted or trademark protected thing (that you are
using without my permission)" when they say, "IP" and we usually
mean, simply, "design component" (whether it's legally licensed or
open source or shared between two designers within the same company).
Instead of "IP", please let's just say "design component," or
"libary," or "verilog module."
</aside>

> Customers no longer need
> to sift through
> new code trying to figure out how to use it. That information is available
> in the IP-Xact files.
> This enables us to do a "plug-an-play" tool set.
>
> You can create a SOC builder tool so that once a piece of IP is entered into
> your design environment
> that it can automatically add it into the library of available components.
> You can select it and
> instantiate it into your IP with schematic capture. You will see a symbol
> with all ports and parameters
> that you can configure and interconnect.

Schematic capture? Is this a PCB design tool?

>
> When you simulate your IP then the tool flows will build all subcomponents
> and load them into the tool.
>
>
> The spirit consortium realized that nobody in this industry was ever going
> to modify any of their legacy
> code in order to be compatible with some new standard so they designed
> IP-Xact to work with any way that
> you package your IP. Put your files and directories anywhere you want and
> name them anything you like.
> IP-Xact creates new files where you can tell the tools where you put things.
> You legacy code is untouched.
>
> IP-Xact created a naming standard that allows any engineer to create a
> module with a name that is unique
> through out the entire industry now and into the future. If you create names
> by picking something out of
> thin air then there is a good chance that your user never see a naming
> collision. But the train wrecks
> that name collisions can cause says that we need to do better than something
> than"probably works". We
> need something that will work in all cases.

Worrying about naming collisions sounds like a problem that needs to
be solved in the HDL we use. For example, Systemverilog finally gave
us namespaces (called, packages, confusingly enough), but maybe they
are still to clunky?

>
> IP-Xact also restores the schematic capture data formats back to our
> industry. Back in the 70's and 80's ICs
> were designed using schematic capture tools. Schematics of instantiated
> components were saved in .sch files.
> A simply click would create a symbol for a schematic and save it in a .sym
> file that had a pointer to its
> .sch file.
>
> Large designs could break a schematic into multiple pages and the symbol
> into multiple symbols. You could not
> do a PCB design today if you had to create one symbol with thousands of
> pins, you have to break it up.
>
> We lost this in the 90's when HDL/Synthesys replaced schematic capture for
> design entry and these were all
> replaced by a single .v or .vhdl file.
>
> This was fine for the component designers who were doing leaf cells since
> they were treated like undividable
> blocks. But this was not good for the architects that selected,configured
> and interconnected the leaf cells.
> Having the multiple file structure gave them a lot of flexibility for
> reusing circuits in more than one design.
>
> The IP-Xact component file is essentially a .sym file and the design file is
> a .sch file.

Again, I'm totally lost here. Maybe because when I left college
everyone was already using HDL's. This sounds, again, like something
that our HDL should solve for us. Like properly using
modules/interfaces/classes, maybe?

I like the sound of this.

> It also has problems because it has omitted allocating space for some needed
> data items. You need some data that
> IP-Xact doesn't cover then you have to use a vendor extension. You should
> never have to use a VE for any data
> if it is impossible to build the tool without it.

This sounds extremely sane and rational as well.

> Finally IP-Xact is missing the "IP-Xact Design Handbook". Standards are
> pretty dull and really only tell you about
> the "Whats". Every standard needs some author to write a handbook that also
> tells the "Whys and Hows". Look at
> Ken Parkers Boundary Scan Handbook for a good example.
>
>
> So what should Freecellera do? My suggestions:
>
>
> 1) Use IP-Xact for all tools that we create or support. If IP does not
> support IP-Xact then someone will need to create
> the IP-Xact files. You will need to dig out that information anyway to
> configure the tool but with IP-Xact it is only
> done once.

This is not clear to me. If Freecellera, for example, creates a
verilog/vhdl mixed-language simulator, how would it use IP-XACT, and
why?

> 2) Refactor IP-Xact into appropriate dot levels and release that as
> documentation.
>
>
> 3) Write the "IP-Xact Design Handbook". Somebody has to do it and we might
> as well make ourselves usefull.

I think overall I need more examples of problems and how IP-XACT
solves them. More use cases. I understand the register generation
use-case that I've seen before (because every team writes a register
generator at some point...which probably hints at a Freecellera
opportunity, by the way), and I can understand generating
HDL+documentation for other boring components in the same way. Beyond
that I (and presumably not *just* I) need help understanding the
what's and why's.

Bryan

[Erik Jessen]

Bryan,

First - thanks for asking!  If it's not clear to you, then I bet it's not clear for others.  It's a lot better to get terms clear, rather than spend a bunch of time arguing, only to find out we were using different meanings for things.

"IP" - in general, *everything* is intellectual property.  Somebody owns everything - but what one can do is write a license agreement so that everyone else can use it for free ("copyleft" and such terms are used).  After all - you can't give something away if you don't own it...

IP-XACT is actually a general-purpose tool: capture schematics for PCBs, IC designs, systems built up of boards + the software that runs on them.

IP-XACT also allows for capturing configuration-management (i.e. revision control).  A big problem with normal IP standards is there's no way to use two versions of the same IP in your design in two different places.  What happens is that you get block "A" built with version X of your IP_core.  And someone else builds block "B" with version Y of your IP_core.  But they both use the same module name for the IP_core ("module IP_core").  Now you want to build mega-block C that has instance of A and B in it.  Well, you're stuck: you can either use version X everywhere, or version Y everywhere.  BUT - they may be explicitly documented as being non-compatible (maybe somebody tried to update A to use version Y, but found problems).  And even if there's no explici docs against it - it might not work, and you've have no way of knowing, and no way to debug if it happened (maybe it's PCIe, and it requires very special knowledge to know how to change your blocks to switch from version X to Y.)

So: what you want to do is have everyone reference the specific version of the module to use in each place.

Equivalently: you go from block A creating an instance of "IP_core" to something live "IP_core_v_X" and block B uses "IP_core_v_Y".

Anyways, you get the idea - IP-XACT gives you the same capabilities as board designers have always had.

You also run into problems if two vendors release IP with the same name, etc.

Note that Verilog modules can't be placed in packages (and man, I wish they could have been - it'd have solved some headaches).  But even if SV supported it, you still have tons of legacy designs that you need to be able to work with.

"packaging" basically means capturing all the info needed to use the IP.  All of its dependencies, configuration management, scripts to process it, documentation, etc.  And of course pointers to source-code files.

My personal vision is that IC design is going to wind up looking a lot like board design - simply because it has to, to be as fast as possible.

How would Freecelera use IP-XACT?
Well, a really good example would be any test-cases we create.  IP-XACT is great for capturing all of that info: the source code, testbench, documentation, how to run the test, and how to determine pass/fail.

Some issues that I've experienced with IP-XACT:

a) I did a lot of testing of the standard, and found that Accellera really hadn't "used IP-XACT in anger" - there were things that when you actually tried to really use it (as in, test it) you found points that were vague or incomplete or even in a few cases subtlely wrong.
b) For whatever reason, IP-XACT didn't choose to use the exact same register-field values as UVM.  (or vice-versa). So if I was to create a new version of IP-XACT, I'd change it to use UVMs field (but with a large number of additions, just so that all the screwy cases people use are captured concisely- we leave it up to others to implement RTL generators and testbenches).

BTW - as far as "writing our own RTL generator" - it's definitely doable.  And then use UVM's builtin testbenches to verify.

I hope this helps!

Erik

--
You received this message because you are subscribed to the Google Groups "Freecellera" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freecellera...@googlegroups.com.
To post to this group, send email to freec...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/freecellera/CAPY2A7Oou6v6b3H%3DQmuFX_%3DeNo3aFna_oetTtPPT0dryCe0cow%40mail.gmail.com.

[Ouabache Designworks]

On Saturday, January 2, 2016 at 6:44:22 PM UTC-8, Erik Jessen wrote:

I agree with all 3.

Some other thoughts:

a) I would propose also to add some Freecelera-official extensions to cover places where IP-XACT didn't address things.

Do we need to add schema to freecellera.org to do this?

 

b) I'm sure that each of the huge companies has their own internal standard extensions; it would be wonderful if we could get them, so we could look them over.  I'm a great fan of copying good ideas - and hopefully one or more of those big companies would like the idea that we're working to make the standard more standard.

That would be nice if they are available. Theres a tool called kactus2 that has its own extensions, I'll look and see if they published anything
 

c) One thing IP-XACT does NOT have is clear definitions on some terms: e.g. something you can run through a unit-tester.  So a "unit-test-suite" of examples is needed to verify IP-XACT parsers.  I'm thinking of what they have for VHDL: you run the compatibility suite, and you should PASS every good example, and generate an error on every bad one.  I found a number of holes in the IP-XACT standard when I wrote such a suite.  We will likely need to do minor clarifications or alterations to the standard to close those holes.  Not a big deal - I would expect we could release a Python script to map from official IP-XACT to FREE-XACT (or whatever we wind up calling it).

I suspect that testing was do to prove that it worked. You really have to test to prove that it dosen't work.
IP-xact was designed by committee and it shows. Most successful projects have a single leader with a vision who can veto any attempt to deviate from that vision.  Look at linux for a good example. You might not agree with everything Linus Torvalds does but he did get a lot of people to create a very useful piece of code. That is why I suggested partitioning from the bottom up. We only remove the parts that really work and are needed by real  tool flows. Eventually all the bad stuff floats to the top and we simply ignore that level.

 

d) how does one go about the partitioning problem?  I'm trying to think of partitioning that makes sense?  Pull out support for synthesis, FW, etc.?

The only way to do this is by performing a simple exercise. It is the first day at your new job as an IC designer at acme inc. You have logged into your workstation to find a complete set of IC design tools and documentation along with email from your boss detailing your first design assignment.

    name the first tool that you will run.

    describe what is does and the algorithms that it uses

    list the IP-Xact files that it touches and what data it accesses.

    repeat until you are done.

When you reach a point where you have accomplished a minor goal then take your IP-xact list and call it 1685.1 and label it with the name of your accomplishment and clear the list.

Continue on until your next accomplishment and call that 1685.2. When you finish your design then you can throw away anything that wasn't pulled into a dot level



John Eaton

[Erik Jessen]

I looked at Kactus2; unfortunately, they're still on the old IP-XACT standard, not the current one.

I wish I could claim that IP-XACT had been tested "to prove that it worked" - that's what I was doing - was writing an IP-XACT parser/analyzer/generator.  And I ran into a lot of questions.  What I suspect happened is that it was just easier and faster for the big companies to define their own internal standard, than it was to try to get the official one fixed.  Where i'm going with this is - since we're not an official standards body, and have no market-share to protect - we can fix the standard as we run into issues.

I could see the following for subsets:

a) what's needed for schematic-capture (nothing on how to process files, FW, etc. - just raw data).  No support for Java code, etc.

b) add Java (which will be necessary for next addon)

c) add process/scripts

d) add cosim support (as an extension to the language - capture DPI, Matlab, etc.)

I wish I could see more breakdowns - nothing comes to mind that would be useful

--
You received this message because you are subscribed to the Google Groups "Freecellera" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freecellera...@googlegroups.com.
To post to this group, send email to freec...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/freecellera/5373bef9-897f-460d-a307-56f3db2366e6%40googlegroups.com.

[Ouabache Designworks]

On Saturday, January 2, 2016 at 9:14:25 PM UTC-8, Bryan Murdock wrote:

First of all, thanks for the background and history.  I have come
across IP-XACT a few times, but only briefly.  It was always presented
to me as a way to specify something bog-standard (usually registers)
in XML and then have a tool generate code (verilog, vhdl, c, c++,
etc.) and documentation (word, html, pdf, etc.) from that XML.
"Packaging IP" was never mentioned to me.

The spirit consortium stood for Standard structure for Packaging,Integrating,and Reusing Ip within Tool flows.
 

>
> This standard was sorely needed in our industry. It tells the IP creators
> exactly how to
> package their code for delivery to their customers.

It's not clear to me what packaging means here.  I don't think you
mean like, should we use a zip file, or a tar.gz?

Think of it like a moving company. The movers aren't going to show up and grab stuff off of your shelves and dump it in the van. You first put your stuff into boxes and label each box. They then load , transport and store your boxes. They never need to open them.


If you do an IC design and put all of your hdl files in one directory then it will be a real mess if someone wants to reuse one of your subblocks. They would have to copy your entire chip and surgically remove the designed block. This can be real bad if you also have
other blocks that you do not want them to see. So we package every subblock that we use in our chips in their own separate directories. Each directory contains all the files needed for that block and no files that are used by any other blocks. We give this directory a unique name and store it in a safe location under a Revision Control system. Anyone wanting to reuse that block can clone it from its master location.

Zip and compressed files really have no place in a modern IC tool flow.  RCSs can remember where the code came from so that you can check for updates or push bug fixes. You can compare your copy with the source to see if anything has changed and you keep a detailed record of what changed when and by who.



 

<aside>
Also, I think now is a good time for me to request that we, as the
Freecellera group, remove "IP" from our vocabulary.  Look at the
explanations of IP-XACT from Acellera and from Wikipedia:

http://www.accellera.org/activities/working-groups/ip-xact

https://en.wikipedia.org/wiki/IP-XACT

Wikipedia avoids using the ambiguous term "IP" and it is a more clear
description of what IP-XACT is.

IP stand for Intellectual Property, which is a complete misnomer in
and of itself (see: http://www.gnu.org/philosophy/not-ipr.en.html),
but we in the chip design world don't even use that misnomer the same
way everyone else in the world uses it.  Most everyone means "my
patented or copyrighted or trademark protected thing (that you are
using without my permission)"  when they say, "IP" and we usually
mean, simply, "design component" (whether it's legally licensed or
open source or shared between two designers within the same company).
Instead of "IP", please let's just say "design component," or
"libary," or "verilog module."
</aside>

Good point
 

>
> You can create a SOC builder tool so that once a piece of IP is entered into
> your design environment
> that it can automatically add it into the library of available components.
> You can select it and
> instantiate it into your IP with schematic capture. You will see a symbol
> with all ports and parameters
> that you can configure and interconnect.

Schematic capture?  Is this a PCB design tool?

Back in the day the best way to design logic was to use  schematic capture. In the 70's board designers would use 7400 ttl parts by plopping gate symbols onto a board schematic. As designs moved from boards into chips the chip houses used those same symbols to call their macros so that an entire board could be converted simply by changing your library.

By the end of the 80's it was clear that you couldn't plop gates fast enough to keep up with growing chips so we went to a HDL/Synthesis tool flow. If you were a leaf cell component designer then it was great but if you were a system architect then it was bad. Architects didn't have a problem because their blocks contained 1,000's of gates each and they could keep up. Plus architects always like to see a block diagram of the entire system laid out to show signal flows and separations. That was how they did their schematics. Once the team adopted HDL entry then they had to find another tool to create their block diagrams.

The tool that the HP IJBU architects used was Microsoft Visio. It was purely a graphic and had no connectivity information from the hdl. It was a giant step back.

The Soc creation tools that we now have are really just schematic capture. Gui's are a great way to enter data up to a point.






 

>
> IP-Xact created a naming standard that allows any engineer to create a
> module with a name that is unique
> through out the entire industry now and into the future. If you create names
> by picking something out of
> thin air then there is a good chance that your user never see a naming
> collision. But the train wrecks
> that name collisions can cause says that we need to do better than something
> than"probably works". We
> need something that will work in all cases.

Worrying about naming collisions sounds like a problem that needs to
be solved in the HDL we use.  For example, Systemverilog finally gave
us namespaces (called, packages, confusingly enough), but maybe they
are still to clunky?

Don't spread this around but IP-Xact is a HDL. We don't like to mention this to avoid being sucked into all the language wars but it is an HDL designed for architects.

Picking component names has the same problem that assigning MAC addresses and usb identifiers has in that you  usually need a governing body to assign names in order to prevent name collisions. IP-xact solves this problem by using internet URLs. They are already assigned and guaranteed to be unique.





 

>
> IP-Xact also restores the schematic capture data formats back to our
> industry. Back in the 70's and 80's ICs

> The IP-Xact component file is essentially a .sym file and the design file is
> a .sch file.

Again, I'm totally lost here.  Maybe because when I left college
everyone was already using HDL's.  This sounds, again, like something
that our HDL should solve for us.  Like properly using
modules/interfaces/classes, maybe?

You are trying to stretch a simulation language and make it into a design language. IP-Xact was created to be a design language.  As I have been working with IP-Xact I find myself taking tasks that verilog used to do and performing them in IP-Xact instead. It gives a cleaner solution.


 

>
>
> 1) Use IP-Xact for all tools that we create or support. If IP does not
> support IP-Xact then someone will need to create
>    the IP-Xact files. You will need to dig out that information anyway to
> configure the tool but with IP-Xact it is only
>    done once.

This is not clear to me.  If Freecellera, for example, creates a
verilog/vhdl mixed-language simulator, how would it use IP-XACT, and
why?

If you add a new block into your design and rerun the simulation it will locate, build and load that new block without you ever having to do any setup.

The best way to look at IP-Xact is that it is a data sheet for your block. But instead of a pdf file that you have to read and reenter into your tool flow setup, IP-Xact  is directly read by your tools so you don't have to do anything.

The really neat thing is that if you put a data sheet into a star trek replicator it will spit out the actual object. We can do that for IP-Xact as well. You don't ship IP-Xact with your HDL, You only ship the IP-Xact and we generate the HDL on site.




 

> 2) Refactor IP-Xact into appropriate dot levels and release that as
> documentation.
>
>
> 3) Write the  "IP-Xact Design Handbook". Somebody has to do it and we might
> as well make ourselves usefull.

I think overall I need more examples of problems and how IP-XACT
solves them.  More use cases.  I understand the register generation
use-case that I've seen before (because every team writes a register
generator at some point...which probably hints at a Freecellera
opportunity, by the way), and I can understand generating
HDL+documentation for other boring components in the same way.  Beyond
that I (and presumably not *just* I) need help understanding the
what's and why's.

Bryan

If we work through some examples to partition off the dot levels then you will see how usefull it can be.

 

[Olof Kindgren]

Hi guys,

A few notes here.

1. I see that you mention Kactus2 here. We had the pleasure of having two of the Kactus2 developers speaking at orconf earlier this year, and there was a lot of interest in general in IP-Xact from the Open Source Silicon community there. (all videos from orconf2015 are available here btw https://www.youtube.com/watch?v=7vrC3zZ5Av4&list=PLUg3wIOWD8yoX2ECfeU_QP5snbu2Zs1Wp). They are currently working on rebasing all their stuff to IP-Xact 2014. I think they had planned to release it in december, but it looks like they are slightly behind schedule. I have also been working with them to create a best practice demo with an OpenRISC-based SoC to show off both IP-Xact and Kactus2. Hope to release that once they have got their new version out

2. Regarding packaging of IP, this is one of the key areas I have been working on with my own tool, FuseSoc (https://github.com/olofk/fusesoc). I've been working on this in my spare time for the last four years. All the way from the beginning I had the idea to somehow leverage IP-Xact as much as possible, but it has taken until now to realize how to do this in a good way. At the heart of FuseSoC are my so called .core files, that describe each IP (which files they consist of, its dependencies on other cores, which testbenches are available, where to get the IP core and so on). Up until now they have been the only source of metadata for each IP core, but I'm now at the point where I will let the .core file hand off much of this to IP-Xact files instead. One thing however that I don't want to put in the IP-Xact files are how to download and extract the cores and which other cores they depend on. I see this kind of packaging information as an additional layer outside of IP-Xact. This can be compared to how software package managers do it (AppStream files desribe desktop apps, but they are still packaged in an RPM/deb package), or in networks (The IP-Xact files is an IP packet (Ha! Pun intended) and the .core files is the ethernet frame). This also means that FuseSoC can handle cores for which no IP-Xact files are available, either because they haven't been written, or because it doesn't make sense to do a IP-Xact file for certain components.

Happy to see some interesting discussions in this area

//Olof



 

[Ouabache Designworks]

On Sunday, January 3, 2016 at 11:41:19 AM UTC-8, Erik Jessen wrote:

I could see the following for subsets:

a) what's needed for schematic-capture (nothing on how to process files, FW, etc. - just raw data).  No support for Java code, etc.

b) add Java (which will be necessary for next addon)

c) add process/scripts

d) add cosim support (as an extension to the language - capture DPI, Matlab, etc.)

I wish I could see more breakdowns - nothing comes to mind that would be useful

Erik,

Start at the very beginning of a design and work from there. The first thing that you have to do is decide where to store your code. The number one rule in design for reuse is to never ever copy data in a database. Everything is assigned to one master location and anyone who needs it must fetch it from that location. If you work for a corporation then that location will be somewhere up in the corporate cloud guarded by IT minions and under revision control. When you start a new design the corporate librarian will create a new repository for you and populate it with an IP-Xact catalog file.

Your first task is to clone that repo into your local design environment. Your tool set has a repoman tool that will download any repository when given the vendor,library and component names.

Repoman uses a registry database of key value pairs where the key is "::${vendor}::${library}::${component}:: and the value is the absolute directory name of the repository on the server. This will let you clone it into your workstation.

So how do we create the registry database? Since every repo has an IP-Xact catalog file then we crawl through the servers entire file system looking for catalog files. When we find one we parse out the vendor,library and component names to make the key and since this file is inside the repository then the repos absolute pathname will be the leading substring of the catalog's filename.

Theres only one problem.

The catalog file's absolute filename is in the form   ${home}${lib_path}${repo}${xml_path}${filename}.xml. The convention established in IP-Xact is that the catalog file will contain a field for the ${xml_path} variable so that you can locate the ${repo} directory relative to the catalog file. It doesn't exist. So if we want a clean solution we have to work around it.


25 Years ago when I worked on a chip design we had one repository for the entire chip. 10 years ago we were up to 3 repositories. One for the chip, a second one for all the Si vendors files ( separate so that they couldn't see our rtl) and a third with a couple of hundred reusable blocks that were ready to use in any chip.


Today we have 100's or 1000's of repositories. Those reusable blocks are now each in their own repository and our 5 million gate designs are now 500 million gates. Cloning repos has to be automated.


So you call repoman with the full vlnv of your top level component. After fetching its repo it then loads it IP-Xact component file from the repo and checks for any hierarchical references to a Ip-Xact design file. If so then load the design file and look for any component instantiations. The repoman runs itself recursively on the vlnv of the instantiate component. One command  loads the entire chip.


IP-Xact catalog,component and design files.

Vlnv identifier, xml_path, hierarchical reference and componentInstance


Thats 1685.1

Start adding views , filesets , generators, ports and parameters until you can create a symbol and filelist and call that 1685.2

Add businterfaces etc for 1685.3

Add registors 1685.4

etc


John Eaton


 

 


 

[Olof Kindgren]

Hi John,

Is the repoman tool you describe a fictive tool, or a real one (only repoman tool I know is from gentoo Linux)? Haven't dug that deep down into IP-Xact tooling, but it sounds very much like what I'm trying to achieve with the first stage of FuseSoC

//Olof
 

[Ouabache Designworks]

On Sunday, January 3, 2016 at 10:24:54 PM UTC-8, Olof Kindgren wrote:

Den måndag 4 januari 2016 kl. 02:00:35 UTC+1 skrev Ouabache Designworks:

Hi John,

Is the repoman tool you describe a fictive tool, or a real one (only repoman tool I know is from gentoo Linux)? Haven't dug that deep down into IP-Xact tooling, but it sounds very much like what I'm trying to achieve with the first stage of FuseSoC

//Olof
 

 

Hi Olaf,

Its semi fictional. My current socgen release only supports 1685_2009 so it doesn't know about IP-Xact catalog files. I do have two scripts that together perform a similar  function. The first one scans the entire design environment for any xml file and creates a BerkeleyDB file
with the registry. It gets about the ${xml_path} problem by requiring that all repo names must match the component name.


I have a second script that builds a work area for generated files. It starts by symbolically linking the repo of the top level component into the work area and then recursively links all the subblocks as well.


I will be converting this to 1685_2014 and hosting my IP files on github so I will have an actual repoman tool.

John Eaton

[Bryan Murdock]

On Sun, Jan 3, 2016 at 1:17 PM, Ouabache Designworks <z3qm...@gmail.com> wrote:
>
>
>
> On Saturday, January 2, 2016 at 9:14:25 PM UTC-8, Bryan Murdock wrote:
>
> Don't spread this around but IP-Xact is a HDL. We don't like to mention this to avoid being sucked into all the language wars but it is an HDL designed for architects.

Got it. Reading the rest of what you and Eric wrote I was getting a
much clearer picture of what IP-XACT is really trying to do. The
above statement solidifies that. And don't worry, I won't tell :-)

I think I would summarize this all up as saying, Verilog and VHDL are
not only falling short as verification languages (hence people
invented verification languages such as Vera, Specman, and
SystemVerilog, and the associated *VM "methodologies"), they are
falling short as design languages too (hence, IP-XACT).

Supporting legacy stuff makes it very difficult to come up with good
solutions to either problem. The verif languages and *VM's all make
me sad. Using XML as a language (IP-XACT) makes me quite sad too, but
I understand exactly how we got to where we are with both of those.
We needed to support legacy verilog and vhdl code.

A little off topic for this thread, but I'm afraid Freecellera is
going to have to support legacy code too, or we just won't get
adoption. GNU wasn't very innovative at first, they mostly just
duplicated existing tools with a few added niceties (aside from the
huge nicety of being Free). We might have to do the same.

Bryan

[Ouabache Designworks]

On Monday, January 4, 2016 at 12:12:26 PM UTC-8, Bryan Murdock wrote:

Supporting legacy stuff makes it very difficult to come up with good
solutions to either problem.  The verif languages and *VM's all make
me sad.  Using XML as a language (IP-XACT) makes me quite sad too, but
I understand exactly how we got to where we are with both of those.
We needed to support legacy verilog and vhdl code.

A little off topic for this thread, but I'm afraid Freecellera is
going to have to support legacy code too, or we just won't get
adoption.  GNU wasn't very innovative at first, they mostly just
duplicated existing tools with a few added niceties (aside from the
huge nicety of being Free).  We might have to do the same.

Bryan

IP-Xact does support legacy code. It treats legacy code like a leaf cell but you can still use it to old code to  new chip.

John Eaton

 

[Erik Jessen]

I agree that Freecelera will need to support legacy designs.

But I don't see any particular problem with that - in the minimal case, IP-XACT will just capture the wiring and components - essentially the schematic and BOM for a PCB.

But I think that the first problem is that one needs a way to create/edit/lint IP-XACT databases.  Otherwise, any tools written to process those designs and output useful stuff will forever have problems due to malformed input.

There's a saying in software that 80% of the work is input validation.

Erik

--
You received this message because you are subscribed to the Google Groups "Freecellera" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freecellera...@googlegroups.com.
To post to this group, send email to freec...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/freecellera/7ac2eefe-f3a1-4652-a287-2d90e3db977e%40googlegroups.com.

[Olof Kindgren]

FYI regarding my stance on IP-Xact olofkindgren.blogspot.com/2016/01/fusesoc-and-ip-xact.html
Comments are appreciated

[Ouabache Designworks]

On Thursday, January 14, 2016 at 1:46:19 PM UTC-8, Olof Kindgren wrote:

FYI regarding my stance on IP-Xact olofkindgren.blogspot.com/2016/01/fusesoc-and-ip-xact.html
Comments are appreciated

 

With the premise that double documentation is a bad thing,

Olaf,

It is not a bad thing, it is a horrible thing that must be crushed every time it rears it's ugly head.

The number one rule in design for reuse is to never ever copy data in a data base. Everything is assigned to one location and anyone who
needs that data must get it from that location.

It is very tempting to fix problems by copying data but that is always a short term fix that will probably cause bigger problems later. By later I mean
possibly decades. Copying data is a hack and has no place in our tool flows.

That doesn't mean that you cannot have the same data in multiple files, You simply have to designate one of them as the "Official Master" and all the others
are generated from the master at the time of use.

The IP-Xact files should be the Master because it is an IEEE standard and you are more likely to find IP with IP-Xact vs IP with FuseSoc core files. So
we generate the core files when we download the component repository. We update this any time the Master is modified.

We do have to start with the basics and identify only those IP-Xact features that work and we can support. Some things like vendor extensions will never work.
A lot of IP-Xact assumes that you have a single authority that can provide tools, busses and vendor extensions for everyone. But the reality we live in a distributed
world where every repo comes with its own world and we have import that as well. We need to develop and prototype a means to do this to show the world what the
IP-Xact committe should have done.

Here's how it should work:

1) Component designers  create IP with IP-Xact files and put them in opencores.org, github.com etc repos.

2) Component designers create a repo somewhere that contains an index file. The index file lists everyone of their components with:

    a) Vendor,library and component names
    b) Host repository
    c) component repository name
    d) repo type (git,subversion,cvs etc)



3) Socbuilders create a directory on their workstation for the design environment and downloads fuseSoc into it.

4) Socbuilders edit a fuseSoc config file and add an entry for each  host/repo/indexfile


5) Socbuilders run repoman tool with the vendor/library/component name of their top level design.


At this point the repoman tool should download each and every indexfile and parse it info into a registry. Then it uses that registry
to download the toplevel repo and searches for all of its IP-Xact files. It can then generate the core files at that time.

It can also follow any hierarchial references down and recursively download every subcomponent needed for the build.


John Eaton



 


























 

[Olof Kindgren]

Den fredag 15 januari 2016 kl. 20:34:40 UTC+1 skrev Ouabache Designworks:

On Thursday, January 14, 2016 at 1:46:19 PM UTC-8, Olof Kindgren wrote:

FYI regarding my stance on IP-Xact olofkindgren.blogspot.com/2016/01/fusesoc-and-ip-xact.html
Comments are appreciated

 

With the premise that double documentation is a bad thing,

Olaf,

It is not a bad thing, it is a horrible thing that must be crushed every time it rears it's ugly head.

Hi John,

Thanks for the comments.

I really do agree with you completely here. I just chose to not let my words betray my true feelings :)

The number one rule in design for reuse is to never ever copy data in a data base. Everything is assigned to one location and anyone who
needs that data must get it from that location.

It is very tempting to fix problems by copying data but that is always a short term fix that will probably cause bigger problems later. By later I mean
possibly decades. Copying data is a hack and has no place in our tool flows.

That doesn't mean that you cannot have the same data in multiple files, You simply have to designate one of them as the "Official Master" and all the others
are generated from the master at the time of use.

The IP-Xact files should be the Master because it is an IEEE standard and you are more likely to find IP with IP-Xact vs IP with FuseSoc core files. So
we generate the core files when we download the component repository. We update this any time the Master is modified.

This is my intention as well.  I will however not let the flaws in IP-Xact hold back my development on FuseSoC. Hopefully the standard will catch up, and my additions will not be necessary.

We do have to start with the basics and identify only those IP-Xact features that work and we can support. Some things like vendor extensions will never work.
A lot of IP-Xact assumes that you have a single authority that can provide tools, busses and vendor extensions for everyone. But the reality we live in a distributed
world where every repo comes with its own world and we have import that as well. We need to develop and prototype a means to do this to show the world what the
IP-Xact committe should have done.

Yes. This is a bit awkward. I wonder how many different VLNV there are for example for an SPI or I2C interface. I pretty much assume that everyone is writing their own, which makes it incompatible. We are about to launch librecores.org. It is not intended as a code hosting site, but I've been using it already as a place holder for the vendor part in my IP-Xact files, and I've been secretly hoping that other people will use this as well. Just to have a well-defined vendor name for common interfaces.

 

Here's how it should work:

1) Component designers  create IP with IP-Xact files and put them in opencores.org, github.com etc repos.

2) Component designers create a repo somewhere that contains an index file. The index file lists everyone of their components with:

    a) Vendor,library and component names
    b) Host repository
    c) component repository name
    d) repo type (git,subversion,cvs etc)

This is basically how FuseSoC works. The index file you are talking about is the FuseSoC .core file in this context. Right now the .core files contain a lot of extra stuff, but as IP-Xact grows more features, I hope to move more and more of that into the IP-Xact files instead.
 

3) Socbuilders create a directory on their workstation for the design environment and downloads fuseSoc into it.

4) Socbuilders edit a fuseSoc config file and add an entry for each  host/repo/indexfile


5) Socbuilders run repoman tool with the vendor/library/component name of their top level design.


At this point the repoman tool should download each and every indexfile and parse it info into a registry. Then it uses that registry
to download the toplevel repo and searches for all of its IP-Xact files. It can then generate the core files at that time.

It can also follow any hierarchial references down and recursively download every subcomponent needed for the build.

As a core design principle, I have made sure to make it possible to just use FuseSoC for the parts that you want. If you only want it to fetch cores and their dependencies, that's fine. You can continue working in your favorite tool after that. If you also want it to generate a FPGA vendor project file, but continue using their horrible GUI for some inconceivable reason, that's also fine.

John Eaton



 


























 

[Ouabache Designworks]

Yes. This is a bit awkward. I wonder how many different VLNV there are for example for an SPI or I2C interface. I pretty much assume that everyone is writing their own, which makes it incompatible. We are about to launch librecores.org. It is not intended as a code hosting site, but I've been using it already as a place holder for the vendor part in my IP-Xact files, and I've been secretly hoping that other people will use this as well. Just to have a well-defined vendor name for common interfaces.

This is where IP-Xact screwed up. They use the central authority model where if you want to create a component with an Arm AHB bus then you go to arm.com for the busDefinition files. The problem is that Arm has one of the few busses where there is a well-defined vendor as the owner. Most busses like clock,reset,enable etc has no one that is recognized by the industry as the owner so everyone rolls their own busDefinitions. The reality in the industry is  distributed  ownership.


IP-Xact has a busExtension that lets you create a bus and then create a second bus that is the extension of the first. What you really need to do is to let the the second bus rename submembers in the first.


So if you are doing a SOC design then you would create a clock bus with a rising edge submember as part of your design. Then if you import a component with its own clock bus then you extend your clock bus to point to the new designs clock bus descriptor, You tools now map any reference made to their clock bus into yours. You can now connect them together using interconnections. You do this for each and every component that has their own clock definition.


John Eaton










 

[Erik Jessen]

I wouldn't worry about all the various instances out there for SPI, etc.  

At one company I worked at some decades ago, we built a clone of another company's part.  The only problem was - we actually complied to the standard, while they had undocumented bugs that required SW workarounds.

So customers wouldn't buy our parts - they'd have to change their firmware.

So we modified the design to have a bit that defaulted to "bug for bug compatible with original manufacturer" and everyone was happy.

And each controller will have different register maps, pinout names, etc.

One can also simply create ones own busDefinitions - and name them FreeCellera - maybe they're just pointers to someone else's, but at least everyone has a standard.

As far as libraries, I'd use the same setup as Opencores (just to pick one).

One question I had was: what do you do if company X creates a model of company Y's part?  My guess is that it would be:

Vendor = X

Library = Y

So that Vendor is who you'd go look to for updates, documentation, etc.

One final point: we're not after perfection - we're just going to make things better than today.

Even if all we do is capture things so it's easier to find stuff (but not perfect), we've made things much better.

Erik

--

You received this message because you are subscribed to the Google Groups "Freecellera" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freecellera...@googlegroups.com.
To post to this group, send email to freec...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/freecellera/77165c28-014f-4793-a2b1-a52d58b46f3c%40googlegroups.com.

[karls...@verizon.net]

I also go back to schematic/block diagrams and interface hand shaking diagrams for hardware. 

We did "Logic Design" first then physical design with manual simulation and synthesis. 

Today there is a combination of HW and SW so I think a common C# model should be the platform for design.

The generics, string handling(parsing/formatting), Boolean(bool) types, conditional assignments, and OOP classes can define both

hardware and software for interactive debug and simulation.  And the compiler ties everything together.

The hardware has inputs, outputs, gates/LUTs, memory, latches/FFs which are all simple entities.  C# classes have property accessors

for input and output,  arrays, numeric and bool types so classes and modules correspond.

C# and Verilog both have assignments and conditional assignments so formatting the source for a C# class to a Verilog module is realistic..