A Verification Environment Creation Infrastructure for Bus-Based Systems and Modules

by Jorge Carrillo and Paulo Dutra, Xilinx
San Jose, California, USA

Abstract:

We present the Xilinx Platform Specification Format (PSF) for system design and verification. PSF is a plug-n-play infrastructure, which promotes IP core reusability, time-to-market reduction, and IP design capture. Details of the IP core interface are captured to provide information of the system interconnect topology. The PSF infrastructure allows designers to automatically create verification environments for either a hardware module or a large system, by easily adding Bus Functional Model (BFM) components.

On-Chip Buses

Modular design has become a very common practice among system designers due to the increased complexity of systems and the need for reusing each of the different components that form these systems.

Modern system level design tools provide environments and specifications in which modules have a common interface for easy integration. This common interface inherently allows the modules to be reused from one design to another. These environments bring in many advantages to system design, being short design and verification cycles some of the most important.

Industry has adopted several on-chip bus standards to ease the integration and reuse of processor and peripheral cores. IBMÒ created CoreConnect™[1], an on-chip bus-based communications link that enables chip cores from multiple sources to be interconnected to create entire new chips.

Xilinx uses the CoreConnect infrastructure inside Field Programmable Gate Arrays (FPGAs) for all of Xilinx embedded processor designs. CoreConnect defines three different buses: the On-Chip Peripheral Bus (OPB), the Processor Local Bus (PLB) and the Device Control Register (DCR) bus. Both of the Xilinx supported embedded processors, the MicroBlazeÔ[2] soft processor and the IBM PowerPCÒ[3] hard processors have CoreConnect bus interfaces. This allows a designer to create, use, and share peripherals in systems designed that include either of these processors.

CoreConnect Toolkits

IBM provides a set of toolkits for CoreConnect development. The bus functional model toolkits enable simulation and verification of peripheral devices that have one of the CoreConnect bus interfaces. The toolkits are used to reduce development efforts and ensure bus compliance. Each toolkit environment consists of a fixed complex test bench, several generic bus functional models, and a bus functional compiler. These environments allow you to instantiate designs under test, create test cases, initialize models, and detect error conditions.

Creating a test bench is a time consuming task. It involves describing connections and generating test vectors for all different combinations of bus transactions. The CoreConnect toolkits make this task easier by providing pre-written test benches for each of the bus standards that one can edit to include the design under test.

Usage of the any CoreConnect toolkit is simple but still time consuming. The first step involves selecting one of the predefined test bench scenarios based on the bus interface that fits the current device under test. Secondly, one would hand modify the HDL test bench to incorporate the device under test and describe its connections to the bus. After editing the HDL files, the user configures the BFM devices in the test bench. This is accomplished with a file written in a specific language called the Bus Functional Language (BFL). This file contains high level commands to generate or respond to bus transactions on the buses. The BFL File is compiled using the Bus Functional Compiler (BFC) to generate a script file that contains hardware simulator specific commands that will drive the Bus Functional Models at simulator runtime.

Xilinx Platform Specification Format

An embedded programmable platform consists of several hardware components on an FPGA. Programmable hardware components supplied by Xilinx or a third party developers, in the form of soft cores, range from simple blocks of fixed logic to complex, parametizable dynamically generated subsystems. Typical hardware components include processors, micro-controller peripherals, digital signal processing (DSP) cores, IP cores, communications peripherals, on-chip and off-chip memories, buses and bus bridges.

Xilinx created an IP capture infrastructure that offers a wide range of configurable possibilities ranging from multiple processors to multiple bus architectures. All the available components are captured using the Platform Specification Format (PSF).

PSF defines the compatible set of infrastructure files that capture, describe, and handle IP blocks for enabling the Platform Studio automated tools to seamlessly integrate IP blocks into a System On a Programmable Chip (SOPC) solution. The infrastructure files are BBD, MDD, MHS, MPD, MSS, and PAO files. The PSF file set contains a description of the module’s interface. In this paper we focus on the subset of PSF that is related to hardware design. Xilinx first introduced PSF technology in 2001.

The Microprocessor Peripheral Definition (MPD) file defines the interface of the IP. The MPD file lists ports and their default connectivity for bus interfaces. It also lists parameters and their default values. Default parameter or port assignments may be overwritten with values specified in the MHS file, which will be described later.

The Peripheral Analyze Order (PAO) file contains a list of HDL files for synthesis or simulation. It defines the analyze order for compilation. The Black Box Definition (BBD) file manages the file locations of optimized hardware net lists for the black-box sections of the IP design.

The Microprocessor Hardware Specification (MHS) file defines the SOPC, or the hardware description of the system. The MHS captures the configuration of the embedded processor system, and includes the connectivity and system topology. The information included in this file is combined with the information from the MPD file to create a hardware design.

Related Work

Industry solutions similar to PSF include work from the Structure for Packaging, Integrating and Reusing IP within Tool-flows (SPIRIT) Consortium[4], the Virtual Socket Interface Alliance (VSIA)[5], and the Open Core Protocol (OCP) International Partnership[6]. The standards they define share the common focus of unifying the packaging and characterization of IP across the industry. PSF also realizes this goal through the BBD, PAO, and MPD description formats that capture all of the IP design.

PSF extends into the SOPC design space with the MHS description format. The MHS defines the interconnection of the IP blocks in the system. Whereas, the current industry standards only define the packaging of the IP, but do not provide specification of how to define the system topology of the captured IP blocks when included in the system. Compliance with the standards will ensure that IP providers can supply IP in a way that facilitates automatic integration within multiple EDA environments. However, EDA vendors define the system in their own database or format.

SPIRIT differentiates from VSIA and OCP in that all materials created must lead to direct automation benefits in the tool flow. VSIA and OCP define a standard socket interface. VSIA defines a Virtual Component Interface (VCI) that comes as an executable model or machine readable design description. OCP defines a core-centric, busindependent protocol for subsystem communication. The OCP is equivalent to VSIA’s Virtual Component Interface (VCI). The following statements is taken from the OCP specification overview: “While the VCI addresses only data flow aspects of core communications, the OCP is a superset of VCI additionally supporting configurable sideband control signaling and test harness signals. The OCP is the only standard that defines protocols to unify all of the inter-core communication.” The paradigm of PSF follows SPIRIT to accelerate automatic tool flows while also introducing a system description of the SOPC.

Xilinx is not a member of the SPIRIT consortium, VSI Alliance, or OCP International Partnership. The above discussion is based on readings found on the individual organization’s web sites, for only members have access to the documentation.

IP Verification

Typically, there are two methods to verify the correct functionality of a hardware component that has a bus interface: creating a test bench, or; creating a system with other known-to-work components that will create or respond to bus transactions. Creating a test bench involves describing the connections and test vectors for all different combinations of bus transactions. Creating a system with other components requires describing the connections done to the device under test; and programming the other components to generate the desired bus transactions to which that the device under test will respond, or to respond to the bus transactions that the device under test is generating. Programming this device usually involves creating some code, compiling it, and storing it in some memory for the components to read and generate the right bus transactions.

Bus Functional Models (BFMs) are typically used for verification. The purpose of these components is to model the functionality of a bus interface so that they can generate stimulus or respond to bus transactions. The IBM CoreConnect Toolkit includes a set of predefined verification environments that use BFMs. These environments need to be manually edited to include new modules for verification. Manually editing the environments is time consuming because bus interfaces typically include many signals.

The behavior of each BFM is then described in a high level Bus Functional Language (BFL), which describes signals behavior in terms of bus transactions (reads, writes, etc). This BFL file is compiled using the Bus Functional Compiler (BFC) into the HDL simulator specific commands that will trigger the events that the BFMs should perform on the bus.

Bus Functional Models

There are several BFMs available for each bus. In this paper we describe only the OPB models. There are other models available for the other CoreConnect buses.

OPB Device BFM (opb_device_bfm): The OPB device model may act as a master, as a slave, or as both. The master contains logic to automatically initiate bus transactions on the bus. The slave contains logic to respond to bus transactions based on an address decode operation. The model maintains an internal memory, which can be initialized through the bus functional language and may be dynamically checked during simulation, or when all bus transactions have completed.

OPB Monitor BFM (opb_monitor_bfm): The OPB monitor is a model, which connects to the OPB and continuously samples the bus signals. It checks for bus compliance or violations of the OPB architectural specifications and reports warnings and errors.

BFM Synchronization Bus (bfm_synch): The BFM Synchronization Bus is not a Bus Functional model, but a simple bus that connects the various Bus Functional Models in a design and allows communication and synchronization between them. This bus is required in whenever BFM devices are used.

Using the IP capture component of the PSF, one can describe the connections of the Bus Functional Models used for verification. Using the connectivity component of the PSF, one can write a simple specification of a desired verification enviroment. This specification may include one or many BFM components and bus-based modules or systems to be tested. The Xilinx Platform Studio tools, which understand the PSF format can automatically generate the HDL verification environment specified. In the following sections we will describe how we take advantage of the PSF infrastructure and Bus Functional Models to automatically generate IP verification environments.

1: BEGIN opb_device_bfm
2:
3: ## Peripheral Options
4: OPTION IPTYPE = PERIPHERAL
5: OPTION HDL = VHDL
6:
7: ## Bus Interfaces
8: BUS_INTERFACE BUS=MSOPB, BUS_STD=OPB,
                BUS_TYPE=MASTER_SLAVE
9:
10: ## Generics(VHDL)/Parameters(Verilog)
11: PARAMETER NAME = OPB_DEVICE, DT=STRING
12: PARAMETER MASTER_ADDR_LO_0=0x00000000,
                DT = std_logic_vector(0 to 31)
13: PARAMETER MASTER_ADDR_HI_0=0x00000000,
                DT = std_logic_vector(0 to 31)
14: PARAMETER SLAVE_ADDR_LO_0 = 0x00000000,
                DT = std_logic_vector(0 to 31),
                BUS = MSOPB, ADDRESS = BASE,
                PAIR = SLAVE_ADDR_HI_0
15: PARAMETER SLAVE_ADDR_HI_0 = 0x00000000,
                DT = std_logic_vector(0 to 31),
                BUS = MSOPB, ADDRESS = HIGH,
                PAIR = SLAVE_ADDR_LO_0
16:
17: ## Ports
18: PORT SYNCH_OUT = "", DIR =O, VEC=[0:31]
19: PORT SYNCH_IN = "", DIR = I, VEC=[0:31]
20: PORT OPB_CLK = "", DIR = I, BUS = MSOPB
21: PORT OPB_RESET = OPB_Rst, DIR = I,
                BUS = MSOPB
22: PORT OPB_MGRANT = OPB_MGrant, DIR = I,
                 BUS = MSOPB
23: PORT OPB_BE = OPB_BE, DIR=I, VEC=[0:3],
24: BUS = MSOPB
...
25: END

Code 1: Sample IP interface capture file

Interface Description

The IP capture component of the Platform Specification Format provides a mechanism for describing module interfaces. Using this component of the PSF one can capture the interfaces of the BFMs so that the Platform Studio tools can understand them. This interface includes all parameters, ports and properties for each module. A sample IP capture file (MPD) is shown in Code 1. This file describes the interface of an OPB device. The file includes all information regarding the bus interface, the input/output interface, the ports and all parameters for the device.

In the sample MPD file, line 8 shows the definition of the bus interface that the module uses. All the ports that form the bus interface are later described in the same file on lines 20 through 24. There are more ports defined in the real file, one for each of th signals defined in the OPB bus, but were omitted in this paper to keep it short.

1: # Parameters
2: PARAMETER VERSION = 2.1.0
3:
4: # Top level ports
5: PORT sys_reset=sys_reset, DIR=IN
6: PORT sys_clk=sys_clk, DIR=IN, SIGIS=CLK
7:
8: # Components
9: BEGIN opb_device_bfm
10: PARAMETER INSTANCE = my_master
11: PARAMETER HW_VER = 1.00.a
12: PORT SYNCH_IN = synch
13: PORT SYNCH_OUT = synch0
14: BUS_INTERFACE MSOPB = opb_bus
15: END
16:
17: BEGIN opb_monitor_bfm
18: PARAMETER INSTANCE = my_monitor
19: PARAMETER HW_VER = 1.00.a
20: PORT OPB_Clk = sys_clk
21: PORT SYNCH_IN = synch
22: PORT SYNCH_OUT = synch1
23: BUS_INTERFACE MON_OPB = opb_bus
24: END
25:
26: BEGIN bfm_synch
27: PARAMETER INSTANCE = my_synch
28: PARAMETER HW_VER = 1.00.a
29: PARAMETER C_NUM_SYNCH = 2
30: PORT FROM_SYNCH_OUT = synch0 & synch1
31: PORT TO_SYNCH_IN = synch
32: END
33:
34: BEGIN opb_v20
35: PARAMETER INSTANCE = opb_bus
36: PARAMETER HW_VER = 1.10.b
37: PORT SYS_Rst = sys_reset
38: PORT OPB_Clk = sys_clk
39: END
40:
41: BEGIN opb_dut
42: PARAMETER INSTANCE = my_dut
43: PARAMETER HW_VER = 1.00.a
44: PARAMETER C_BASEADDR = 0xffff0100
45: PARAMETER C_HIGHADDR = 0xffff01ff
46: BUS_INTERFACE SOPB = opb_bus
47: END

Code 2: Sample hardware specification file

Generation of Verification Environment

The instantiation and connectivity framework of the PSF allows instantiation of previously captured modules and description of the connections between them. Using this component one can easily instantiate BFM components and devices under test and describe the connections between them by editing a very simple and high level specification that the PSF provides. The Platform Studio tools will automatically read the IP interface and connectivity description from the PSF files to create the customized HDL verification environment based on the specification. As a result, the tools save time by eliminating the need to manually edit the typically complex bus interfaces. An example Hardware Specification file (MHS) that describes this connectivity is show in Code 2.

Figure 1: Sample Verification Environment

In this example we describe the connections of a device under test (dut) instantiated on line 41. We instantiate an OPB bus (opb_v20) on line 34 and connect the device to the bus using a slave bus interface (SOPB). The connection is done by assigning the name of the bus instance (defined in line 35) to the bus interface (line 46). We also connect to the same bus an opb device (opb_device_bfm) using its master-slave interface (MSOPB). This is done in line 14. This device will be used as a master to provide stimulus to the device under test. Finally, we instantiate an OPB bus monitor (opb_monitor_bfm) on line 17 and attach it to the monitor interface of the bus. The monitor will verify that bus transactions comply with the standard. An extra synchronization component (bfm_synch) is instantiated on line 26. This is used for communication and synchronization between bus functional models.

The MHS file is read by the Platform Studio tools to generate the verification environment in the form of a set of HDL files that instantiate the specified modules and describes the connections between them. Today, VHDL and Verilog are the two supported output HDL languages. Figure 1 shows the topology of the hardware specification. The my_device component will be providing all stimuli for the my_dut component. All transactions happen through the opb_bus, which is monitored by the my_monitor component.

After the verification environment is created, one would configure the BFM component to generate or respond to the bus transactions. Code 3 shows an example of a simple high level BFL file that configures the opb device to generate read and write bus transactions. Line 2 defines the hierarchical path of the BFM device to be initialized. Lines 5-8 are examples of 32-bit transactions. Lines 10-20 show how 16-bit and 8-bit transactions are done. All of these commands follow OPB rules for byteenable transactions and data mirroring.

The BFL file is compiled using the Bus Functional Compiler provided in the CoreConnect Toolkits. The compiler generates hardware simulator specific command scripts that are executed at simulator runtime. The resulting simulation will show al the

1: -- Initialize my_master
2: set_device ( path=/system/my_master/my_master/device, device_type=opb_device)
3:
4: -- Write and read 32-bit data
5: write(addr=ffff0100,be=1111,data=01020304)
6: write(addr=ffff0104,be=1111,data=05060708)
7: read (addr=ffff0100,be=1111,data=01020304)
8: read (addr=ffff0104,be=1111,data=05060708)
9:
10: -- Write and read 16-bit data
11: write(addr=ffff0100,be=1100,data=01020102)
12: write(addr=ffff0102,be=0011,data=03040304)
13: read (addr=ffff0100,be=1100,data=01020102)
14: read (addr=ffff0102,be=0011,data=03040304)
15:
16: -- Write and read 8-bit data
17: write(addr=ffff0100,be=1000,data=01010101)
18: write(addr=ffff0101,be=0100,data=02020202)
19: read (addr=ffff0100,be=1000,data=01010101)
20: read (addr=ffff0101,be=0100,data=02020202)

Code 3: Sample BFL file

bus transactions specified in the BFL file. The bus monitor will issue error or warning messages for events that do not comply with the bus specification.

Conclusion

The methodology presented simplifies the verification of hardware components by combining two existing technologies: Bus Functional Models (BFM) and the Xilinx Platform Specification Format (PSF). Using the IP capture component of the PSF, one can describe the connections of the Bus Functional Models used for verification. Using the connectivity component of the PSF, one can write a simple specification of a desired verification environment. This specification may include one or many BFM components and bus-based modules or systems to be tested. The Xilinx Platform Studio tools, which understand the PSF format, can automatically generate the specified HDL verification environment.

References

[1] IBM Microelectronics – CoreConnect bus architecture 

[2] Xilinx – MicroBlaze Soft Processor Core 

[3] IBM Microelectronics – PowerPC 

[4] SPIRIT Consortium 

[5] VSI Alliance 

[6] OCP International Partnership