1.3.2. XVC environment

Simulation performance degradation using Specman is related to the large number of system calls required to directly drive signals at the Hardware Design Language (HDL) level. To overcome this, and increase simulation performance, the eXtensible Verification Component (XVC) passes over transactions, and functions such as write word, using one system call. This enables the PTB to translate this into its operation cycle based signal driving.

Figure 1.3 shows the XVC environment.

Figure 1.3. XVC environment

The XVC can contain the PTW, depending on requirements, but for performance reasons directly interfaces to the Peripheral Test Interface (PTI), within the PTB, with the translator. The XVC performs all high level data formatting and advanced test functions with the PTB generating the basic communications to the PrimeCell.

Although the XVC communicates directly to the PTI the actual PTB performs the same way as in the other environments. This enables the reuse of the PTB across environments, improving the debugging capability.

The XVC master is capable of recording FRBM transactions, that can then be replayed on the FRBM released environment.

The XVC environment is based on the internal development environment, using the same memory map and components. The Figure 1.3 does not show this relationship, it concentrates on the way the XVC links to the PTB because this interconnect is very different from the other environments.

Specman e and SystemC specific implementations

Specman e and SystemC languages have the ability to probe signals at any point within the design, they also have the ability to directly manipulate signals, registers and arrays. Use this feature to optimize the performance. The overhead in the system calls required by these languages, means optimal performance is achieved if the translator communicates directly with the signals at the PI and buffers. This feature configures all the registers, and fills memories in a single system call.

Figure 1.4 shows the Specman/SystemC environment.

Communicating directly to the PI and buffers, enables the Specman/SystemC environment to receive a single call from the simulator to update all registers, from the event bus. This procedure consumes zero simulation time and minimizes the call overhead. This also bypasses the PTI and register address mapping giving best performance for Specman e.

This scenario requires the use of consistent naming for the signals to and from the buffers and PI, together with a well defined timing interface that can accept both the PTI and translator interface. You cannot run the Specman/SystemC environments in any clock domain, but they can be run in an event/transaction driven environment. Only monitor event signals that are changing infrequently. This minimizes the system call overhead, and implies the monitoring of the event signals and the FIFO status. You must also ensure that the monitored signals are glitch free.

Figure 1.4. Specman/SystemC environment

The status, control and event signals are busses with the following naming:

  • status[n:0], where n is the width of the bus

  • control[m:0], where m is the width of the bus

  • event[31:0], for the event bus.

The assignment of signal functions in the busses is implementation specific.

The read and write buffers are implemented as arrays, these are PTB specific in width and depth, and are directly accessible by Specman and SystemC.

Copyright © 2005 ARM Limited. All rights reserved.ARM DDI 0364A
Non-Confidential