IP-XACT best practices

[olofk]

Hi,

I finally started to explore IP-XACT with the intention of creating
bus definitions and interface models for most of the cores we use in
the OpenRISC ecosystem. During my brief encounter I have come across a
few practical issues where I'm interested in guidance on best
practices.

1. Is there a publicly available central registry for common things
like bus definitions? It feels like half of the idea of the standard
is lost if everyone is pusing their own SPI, I2C, SDRAM buses and so
on.

2. How do I treat variants of a bus? The most common bus we use is the
Wishbone bus, and there are a few variants of it. It has seen at least
thee revisions (called b2, b3 and b3) with signals added in each
revision, and it also comes in different widths with 32 and 8 bits
being the most common. It seems to me like I would need to create 3x2
= 6 different combinations to cater this. I'm also not sure what would
be the preferred naming scheme for this. One way is to create six
different versions (e.g. b3.8, b3.32, b4.8, b4.32... etc). Another way
is to give different VLNV names to the different data width
combinations (e.g. wishbone32 with versions b2, b3, b4 and wishbone8
with versions b2, b3,b4). I'm basically looking for best practices for
this.

3. Are the bus definitions parametrizable? I'm using an Open source
IP-XACT tool called Kactus2, and it doesn't allow me to set paramters
for buses, but I haven't figured out if this is a tool limitation or
if the standard prevents configuration. I have come across this issue
for DRAM interfaces where I would like to vary address width, data
width and so on to avoid having a myriad of similar buses.

Best Regards,
Olof Kindgren

[kock]

Hello Olof,

 

Let me comment on your issues.

 

Ad 1) There is no central registery for bus definitions. The idea is that protocol owner publish there own bus definitions. The Accellera IP-XACT Working Group has created some bus definitions that will be published shortly on the Accellera web page. These bus definitions are promoted as best practices. They include SPI, I2C, TLMGP, and JTAG. SDRAM is not part of it yet.

Ad 2) You can use the bus and abstraction definition extends mechanism to make variants of buses. This makes sense for adding signals if it is allowed to connect different versions of bus interfaces (e.g. if it is possible to connect a b2 bus interface to a b3 bus interface. If that is not allowed then I suggest to make different bus definitions (i.e. in which the version element value differs). In order to handle different numbers of bits in a bus, you can also leave out the width of the logical port in the onMaster and onSlave element in an abstraction definition. If you do not specify a width, then you can map any number of bits on that logical port in a bus interface port map.

 

Ad 3) In IP-XACT IEEE 1685-2009 the bus definitions are not parameterizable. In the new revision IEEE 1685-2014, they are parameterizable. To handle address width and data width in 1685-2009, I advice you to omit the width elements in the abstraction definitions.

 

Best regards,

Erwin