DesignWare Introduces Port Monitor Verification IP for the AMBA 3 AXI Protocol

The newly released (February 2007) DesignWare Port Monitor Verification IP for AMBA 3 AXI extends the protocol validation choices for the DesignWare Verification IP solutions for AMBA. The port monitor does the following:

• Improves overall simulation compilation, and runtime performance,
• Reduces the memory footprint
• Maintains protocol checking and coverage collection features at the block and multi-interconnect level.

The port monitor complements the existing bus based monitor and the "AMBA 3 Assured" logo certified master and slave verification IP components.

The port monitor offers a simplified usage model for individual or unlimited port monitoring while maintaining full port level protocol checking capabilities. The port monitor does not require a model memory address map thus resulting in a substantially easier VIP to configure. The port monitor is topology independent, and thus has no restrictions of the number of monitor's you can instantiate. Figure 1 shows a typical use of the port monitor.

Fig 1: Port Monitor Usage Example - Component Level Protocol Checking

When used for component level protocol checking and coverage collection, the port monitor offers a number of advantages over the existing bus based monitor:

• No unused ports to tie off. - Eases instantiation
• No memory map is needed.- Eases configuration
• Coverage report doesn't have unused Src/Dest states.
• Independent of bus architecture (multiple address/data). - Expanded usage

The port monitor supports all of the port level protocol checks offered in the bus monitor.. Therefore it provides in-depth protocol checking and error detection. The port monitor is built from the proven bus monitor protocol checker technology and supports the same set of general model features as the other DesignWare Verification IP components, including comprehensive language support. Verilog, VHDL, SystemVerilog, Vera, and VCS's Native testbench are fully supported. An added benefit of the port monitor's reduced signal pin out is that simulation compilation times are significantly reduced as the simulator can handle the reduced pin out with ease. The resulting compiled binary file size is also reduced meaning that runtime load performance is also improved.

The port monitor complements the bus monitor in designs that contain multiple AMBA 3 AXI interconnects including multiple master and slave ports. The existing bus based monitor has limited capabilities when used across multiple interconnects as source and destination port information is difficult to track when crossing multiple interconnects. The port monitor addresses this limitation by enabling the user to inherently understand the topology as the usage is based in individual instances, regardless of the topology. Source and destination information is readily available to the user in the testbench enabling them to create a scoreboard based environment with knowledge of the individual ports. Figure 2 shows how a port monitor can be used in a system with multiple interconnects.

Fig 2: Port Monitor Usage Example - Multi-interconnect Port Protocol Checking

In addition to the component level advantages, the port monitor offers the following features when used for within a multi-interconnect architecture.

• Supports any number of ports (even more than 64) by using multiple independent instances.
• Independent of bus architecture (multiple address/data).

In this configuration however there are a number of limitations of the port monitor functionality. There are a number of cross port and system level checks that are not supported in the port monitor. However, the port monitor provides the transaction information to enable the verification engineer to recreate the checks within the testbench. This is simplified when using SystemVerilog and VMM, as the activity channel of the port monitor's VMM interface contains all the required information. A system test bench can connect multiple port monitor's channels into a scoreboard, the scoreboard module can then perform the user defined system level checks. Below is a summary of the port monitor limitations when used in a multi-port scenario.

• Does not provide coverage states that involve multiple ports.
• Does not provide warning and error messages that involve multiple ports.
• Does not warn if slave side transfers do not match a master side transfer.
• Does not warn if an address is out of range for the slave device (no memory map).
• Does not track transactions to slave aliases.

As the cross port limitations are not present in the bus monitor when used across a single interconnect in a multi-interconnect design, it is sometimes applicable to use both the port monitor and the bus monitor to access all required coverage points. In this scenario, the bus monitor offers cross port coverage and interleaving checks across a single interconnect within the multi-interconnect design. Figure shows a system with port monitors and a bus monitor.

Fig 3: Dual Monitor Usage Example - Port monitor and bus monitor

The 64 port bus monitor offers significant benefits over the newly introduced port monitor. As the bus monitor is connected to each port of the interconnect, it can then provide cross port information and coverage collection.

In this configuration the bus monitor offers the far more complex tracking and coverage metrics. Below is a summary of the additional bus monitor features when used across an interconnect fabric.

• Supports warning and error checking that require cross-port tracking.
• Supports coverage states that require cross-port tracking.
• Supports memory map to check if the transaction went to the right slave.
• Supports slave alias tracking
• Can track multiple-address, multiple-data architectures.
• Can track master and slave ID's for error checking and coverage.

A number of limitations exist when using the bus monitor

• Footprint always has all 64 ports even ones that are not used. VHDL simulators require all the ports to be connected.
• No more than 32 Masters and 32 Slaves are supported.
• Coverage report has unused Src/Dest states.

Summary In a single component or multi-interconnect scenario, the port monitor significantly reduces the usage complexity while maintaining full protocol checking features and most of the coverage features required by verification engineers. With a reduced pin out foot print, and with a set of simplified configuration parameters, the verification engineer can be up and running with the port monitor within the hour. Recommendation of when to use port monitor:

• Single master to slave AXI interface
• Block level testing without interconnect
• Complex multiple interconnect system that require customized system level cross port checking

Recommendation of when to use bus monitor:

• When there is only one interconnect in the system. A single bus monitor covers all the checks at different levels.
• In a multiple interconnect system that focuses on the compliance of each interconnect
• Where port-to-port coverage is important for that entire system.

The port monitor is offered as part of the existing DesignWare IP solutions for AMBA including synthesizable IP, verification IP and automated assembly using coreAssembler. Additional information on the DesignWare Solutions for AMBA can be found here: Designware AMBA Solutions