ARM Technical Support Knowledge Articles

How do I use the PVBusMapper component?

Applies to: Fast Models



The PVBusMapper component is used for remapping transactions based on the transaction's attributes. When a transaction is made within a 4KB block of memory, PVBusMapper creates a fast channel (if one doesn't exist already) and sends all future transactions to the same 4KB block and with the same transaction attributes through the channel.

When a channel has not been created for a given incoming transaction, the remap behaviour is called. This behaviour allows for the incoming transaction to analyzed and the decision on how to map it to be taken. For example, you could remap the address or the attributes or both for a given transaction.

The example in this article demonstrates the creation of a channels, destroying them and remapping addresses.

Example System

The example system attached to this article contains the following components:

Remapper Component

This component is used to remap transactions in our system according to their attributes. In essence it behaves as a dummy external MMU component with very basic/limited functionality. The component is capable of internally mapping transactions to different ports based on the attributes. For the purpose of this example, the implemented remap behaviour of this component is as follows:

 // The callback behavious is passed a RemapRequest object containing all the
 // information about the transaction. Look at RemapRequest.h for more details 
 // on the available API   
 slave behavior remap( pv::RemapRequest& req_ ) : unsigned
      printf("\nRemapper : Inside Remap Callback\n");
      printf("\t : Obtaining transaction information....\n");

      // Get the transaction attributes (RemapRequest member function)
      attributes = req_.getModifiableTransactionAttributes();
      // Check if it is secure or non-secure
      bool non_secure = attributes->isNormalWorld();
      address = req_.getOriginalTransactionAddress();
      printf("\t :   Address  = 0x%08x\n",address);
      printf("\t :   Security = %s\n",non_secure?"Non-Secure":"Secure");

      if( non_secure )
          // if non-secure transaction translate address, PA = VA + Offset and output transaction on pvbus_m[0] port
          // Get the 4kb aligned base address for this transaction using
          // getPageBase() function and add offset to it.
          new_base_address = (req_.getPageBase() + Offset);
          // This function creates a channel and mapping
          // Only called once for a 4KB block.
          // NOTE: The base address passed as arguement must be 4kb aligned!
          printf("\t : Translating Non-Secure transaction....\n");
          printf("\t :   Incoming VA           = 0x%08x\n",address);
          printf("\t :   4k block base address = 0x%08x\n",req_.getPageBase());
          printf("\t :   Offset                = 0x%08x\n",Offset);
          printf("\t :   New base address      = 0x%08x\n",new_base_address);
          // Use pvbus_m[0] for this transaction
          printf("\t : Remapped to NSRAM (pvbus_m[1]) at physical address 0x%8x\n\n", new_base_address);
          return 0;
          // if secure transaction no translation. Only output transaction on pvbus_m[1] port
          // Use pvbus_m[1] for secure transactions
          // This is connected to SRAM.
          printf("\t : Remapped to SRAM (pvbus_m[1]), not address translation\n\n");
          return 1;

For Non-Secure transactions:

  1. The address of any incoming transaction is remapped by adding the offset (value stored in the Offset register) to the Virtual Address of the incoming transaction.
  2. It then creates a channel for the 4KB block based on the first incoming transaction to a specific address.
  3. The transaction is routed through pvbus_m[0] port of this component which is connected to the NSRAM (non-secure RAM) component.
  4. Once, the channel has been created, all transactions with the same attributes and to that 4KB block will be sent through it to the NSRAM. 
  5. The offset can be dynamically reset to any value by writing to the memory mapped register at address 0x40000000. This also destroys any previous remapping or channels as the offset has now changed.
  6. A channel will be created again upon the next transaction but with the new offset being used to remap the address. 

For Secure transactions:

  1. No offset is added to the incoming Virtual Address.
  2. Instead, all Secure transactions are routed through pvbus_m[1] port of this component.
  3. This port is connected to the SRAM (Secure RAM) component.

The Remapper component also has a memory mapped RW register which contains an offset value used to translate NS accesses. When the register is modified the component has to revoke all currently created channels so that news one with the updated offset can be created.


The revoking of channels can be achieved by calling the allBusMapChanging behavious of the PVBusMapper's control port. This will revoke every currently created channel.

Application code

The application code starts up in the Secure World (Supervisor mode) and writes the value "0xCAFE" to address 0x10000004. The remapper then creates a channel and routes this value into SRAM. The code then writes another value ("0xDEAD") to the same address and this time it can be seen that the Remap callback is not called as the channel has already been created for secure transactions to the address range (4KB).

After this the code switches to the Non-Secure world and performs a write at the same address. Since the attributes have changed the transaction no longer matches the channel created previously, so a new one is need and hence the remap behaviour is called.

Lastly, the core writes to the offset register to change the offset value. This triggers all channels to be removed and hence when perform another transaction to the same address remap is called and this time uses the new offset value for the translation.  

To run the example

  1. Build the example system via sgcanvas.
  2. Launch the simulation and load application code

       model_shell -m <PATH/TO/MODEL>.dll -a <PATH/TO/APP/CODE>.axf

Attachments: System.png , , Untitled.png

Article last edited on: 2013-04-30 09:52:12

Rate this article

Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential