Category: Articles

Three reasons you should use IP-XACT for your registers

ip-xactIP-XACT is a standard for describing electronic components. It is intended for electronic design tools that need to be able to connect different components in a correct way without knowing the full details about what’s inside the component.

However, there is one part of the IP-XACT standard that is useful to you as a digital designer: the memory mapped register description. Here are three reasons why:

#1:  You’re going to use XML anyway

All digital designers sooner or later have to face the mind-numbingly boring task of translating register address maps from some form of high level description into synthesizable RTL code. If you’re anything like me, and I believe many engineers are, you want to automate this process. This is even more true if you are a verification engineer, which means you have to read and write all those addresses and verify that their behavior are according to the specification. So, your high level description needs to support automation of some kind.

You will also realize that to avoid mismatches between the documentation and the implementation, they both need to come from a single source. So you investigate options, and after discarding using Excel (not available on your Unix/Linux servers, difficult to include in scripting) you will probably end up choosing XML as your base source for register data, and generate the documentation from the XML source. You may even generate the RTL code (but I will get back to that in a later post).

And once you have chosen XML there is really no need to develop your own format since IP-XACT is XML and contains everything you need to define your registers. Provided you don’t use very special register types. Which you shouldn’t.

#2:  It’s an IEEE standard, and it’s free!

IP-XACT has been approved as a standard by IEEE, the worlds’ largest professional organization. IEEE handles most of the technical publications and standardizations in the electronics field.

As an IEEE standard it is likely that IP-XACT is thorough, is not going to change without good reason, and will not be replaced by a similar competing standard. Also, it is not under the control of a commercial company. Oh, and it’s free.

#3: There are tools for it!

The IP-XACT standard was developed by Accellera, an organization formed by the major tool vendors in the industry (Cadence, Synopsys, and Mentor Graphics), among others. So the major electronic design tools will support the standard, although mainly for interconnect and integration purposes.

There are also numerous tools for editing general XML files, and a few that are specialized in IP-XACT. One tool I find particularly interesting, since it’s free, open source, and recently updated, is the Kactus2 tool from Tampere University of Technology in Finland.

Where can I get it?

The IP-XACT standard (IEEE 1685-2014) can be downloaded for free here.

You can read more about IP-XACT on the Accellera web site here.

Coding for sharing – two design rules that will make your colleagues happy

RTL code, or any other code for that matter, is rarely written from scratch. Usually you start your design based on someone else’s code. So to make your code easier to understand for your colleagues or any other person that want to use it, consider these two simple design rules.

Divide your design into structural and functional blocks

A structural block is a block that only contain instances of other blocks and the interconnects between them. A functional block contains logic, registers, memories, and all other neat stuff you want to put in your design.

Most designs have this division naturally. A design is usually a bunch of functional blocks that are connected together in a higher level block.

What is important is to resist the urge to add logic in a structural block, even though this may be the easiest place to fix a bug or change the functionality to match your needs. This is for two reasons:

  • Logic outside a functional block will not be included when the block is copied or re-used in other designs, leading to higher risk of bugs.
  • It is not clear who is responsible for the logic in a structural block.

Use this convention, and no logic will be forgotten or misplaced.

Use special names for I/O signals and interconnects

This naming convention makes it much easier to see the structure of the design for a person that is new to the code.

  • I/O signals get a reserved prefix. For example:
    • Input signals are named i_<signal_name>
    • Output signals are named o_<signal_name>
  • Interconnect signals between blocks are named <driver_instance>_<signal_name>

An example is shown in the picture below.


Signal naming in a structural block. The instance “m” of the module “master” sends a request signal to the instance “s” of the module “slave” and receives an acknowledgment.

If these conventions are used it is always clear whether a port of an instantiated block is an input or an output. The driver of a signal can also be easily seen from the name of the signal. So no more backwards tracing of signals in huge interconnect blocks.

Happy code sharing!

Note: if you use VHDL for coding it is not allowed to read output ports. To get around this problem it is common practice to use an internal signal as an alias for the output port, and then connect the alias signal to the output port. It is a good idea to use special names for these alias signals too, such as a_<signal_name> .

© 2019 Bjurling Logic

Theme by Anders NorenUp ↑