Skip to content

The Address Table

This section gives an overview of the address table, which is used by BUTool software to register the nodes for read and write operations.

Overview

Each node in the address table describes a memory address to do read and/or write transactions. Every node contains several attributes, such as it's memory address, read/write permissions, and other user-specified parameters to be used by BUTool software. These attributes are listed in the table below.

Column Name Required? Description
Address Required Register address
Permission Required "r", "w" or "rw"
Name Required Delimited hierarchical name e.g. "STATUS.AMC01.ENABLE" (see naming convention below)
Description Optional Text description. Must be quoted with double quotes ("...")
Mode Optional access mode ("incremental" for block-transfer capable areas)
Size Optional required size for block-transfer capable areas
Parameters Optional storage for useful info
module Optional Link to another xml file to paste in at this address
fwinfo Optional Used in autogenerated HDL

FW INFO Attribute

The fwinfo attribute in the XML address table can be used to create arrays of nodes or memories in the FW.

type=array

This will cause an array of records to be build by the HDL automation instead of several identical records with different names. An example is shown below:

<node id="FF" >
  <node id="CHANNEL_1"  address="0x0000" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_2"  address="0x0800" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_3"  address="0x1000" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_4"  address="0x1800" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_5"  address="0x2000" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_6"  address="0x2800" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_7"  address="0x3000" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_8"  address="0x3800" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_9"  address="0x4000" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_10" address="0x4800" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_11" address="0x5000" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="CHANNEL_12" address="0x5800" fwinfo="type=array" module="file://USP_GTH_Channel.xml"/>
  <node id="COMMON"     address="0x6000" module="file://USP_GTH_COMMON.xml"/>
</node>

In this example the node FF will have an array of nodes called Channel in the Mon and Ctrl records with the range 1 to 12. The _N postfixes can start and end at whatever value you want, but it must be contiguous. Each of these array nodes must be identical and the easiest way of doing this is to use the module tag to make each array entry from the same external XML file.

type=mem

This allows for an embedded memory interface to be generated at this node's address. This can be used to interface with a block-ram, drp interface, or anything with a similar bus like interface. There are two slightly different ways of generating this interface, one for structureless blocks of memory and another for a memory interface where you want to name addresses inside of it.

Generic memory example:

  <node id="MEM1" address="0x100" mode="incremental" size="0x100" permission="rw" fwinfo="type=mem13"/>

This exmaple will generate a memory of 0x100 entries with a data width of 13.

Structured memory example:

  <node id="DRP" address="0x000" fwinfo="type=mem16_0x400" module="file://DRP_USP_GTY.xml"/>

In this example, a memory interface is generated with 0x400 entries and a data size of 16-bits. Any address in the range can be accessed, but you can also use the nodes in DRP_USP_GTY.xml to access specific named registers.

Usage notes

  • The decoder template (located in the slaves.xml for your project) needs to have this mode included (currently template_map_withbram.vhd).
  • To simplify the decoder, the size must be a power of two and start at a multiple of that power of two. (Example: MEM1 above can't start at 0x102)
  • The current template requires a data-valid to be sent back to the decoder otherwise the transaction is assumed to have failed and a bus error is sent back to the user.
  • The template requires a max delay for the data-valid reply. For a blockram this can be small (~16), but some registers in a DRP can take ~300 clock ticks to finish.