Zynq-7000 AP SoC - Zynq BFM Simulation of Packet Processing Unit in PL Tech Tip

Document History

Date	Version	Author	Description of Revisions
11/12/2013	0.1	E. Srikanth	Initial Draft

Introduction

The following tech-tip describes on how to use Zynq SoC Bus Functional Model (BFM) to perform functional simulation of Zynq-7000 based applications. The Zynq BFM is targeted to enable the functional verification of Programmable Logic (PL) by mimicking the PS-PL interfaces and OCM/DDR memories of Processor System (PS) logic.
The Zynq BFM is used to replace the whole of the processing system for the purpose of accelerating the simulation. The principle is simple—what code the processor runs does not matter; the peripheral is only concerned with transactions from the processing system to itself. Simulating a full processing system (and the software that it is running) is a very time-consuming process. Removing all unnecessary gates and modules will greatly speed up the simulation, allowing the designer to verify what is needed in the shortest amount of "wall time". Multiple peripherals can be simulated simultaneously.
The BFM produces a user-specified set of bus transactions that mimic the bus behavior of the processing system. A BFM facilitates simulating and verifying the functionality of an IP core quickly without a complete system having to be built. A BFM generates bus transactions for a device under test (DUT) by utilizing a BFM-modeled processor to write bus transactions using API tasks in a Verilog-based test bench. You can add other peripheral cores that connect to the AXI interconnect and include their operation in the simulation model.
The tech-tip is based on the reference design used for Redirecting Ethernet Header to Cache via PL and ACP port Tech tip. In this tech-tip the Ethernet data received by the Gigabit Ethernet Interface on the Zynq PS is redirected to PL for packet inspection and moved to L2 Cache via the ACP port.

The design files for the this tech tip can be downloaded from the following link : Zynq7000AP_SoC_ZynqBFMSimPacketProcessingUnit_design.zip

System Requirements for running the design:

OS : Windows , Linux
RAM : 10 GB or greater
Hard Disk : 40 GB or greater

Zynq BFM Description

The Zynq-7000 BFM is intended to provide a simulation environment for the Zynq-7000 PS logic. Starting Vivado v2013.3, the processing_system7 block in the block design is replaced with its equivalent Bus Functional Model enabling the user to perform verification of the PL Logic connected to the processing_system7. The Zynq-7000 BFM models the following:

Transactions originating from PS masters through the AXI BFM master API calls
Transactions terminating through the PS slaves to models of the OCM and DDR memories through interconnect models
FCLK reset and clocking support
Input interrupts to the PS from PL
PS register map

Zynq-7000 BFM consists of four main layers. Figure 1 show the Zynq-7000 BFM architecture.

Figure 1: Zynq-7000 BFM Architecture

Configuration: Configuration is implemented using Verilog parameters and is used to configure the Zynq-7000 BFM. Some configuration must be done using configuration APIs.
Function and Task APIs: Verilog tasks and functions that help to set:
- Data path between processing system (PS) and programmable logic (PL) in memory mapped interfaces.
- Control path between PS and PL in register interface.
- Configure the traffic profiles for each ports.
BFM Logic: BFM logic has the PS-PL interface with supporting functionality that contains the AXI interfaces, sparse memory implementation, and the interconnect (arbiter) model as shown in Figure 2.
Signal Interface: The signal interface includes the typical Verilog input and output ports and associated signals.

Figure 2: Architecture Details

The configuration parameters and the APIs necessary for using the Zynq-7000 BFM is described in details in the Zynq-7000 SoC Bus Functional Model Data Sheet(DS897).

Note on limitations of the Zynq BFM: The Zynq BFM cannot emulate any peripheral interrupts that are visible to the Zynq PL. Any PL logic that is using the PS peripheral Interrupts will not have any effect with the Zynq BFM. Instead this peripheral interrupt from PS can be made external and be forced to required value in the testbench as shown in this tech tip.

Design Details:

As in any Zynq-7000 Processing System based block design, the processing_system7 block is instantiated in a common top file along with any desired PL logic with all necessary connections between the PL logic and the processing_system7 block. The processing_system7 block in the block design is replaced with its equivalent Bus Functional Model enabling the user to perform verification of the PL Logic connected to the processing_system7.
The design used in this tech-tip basically comprises of a PL logic called Ethernet Packet Processing Unit.

The Ethernet Packet Processor Unit is a custom IP which redirects Ethernet data received on the General Purpose Master AXI port 1 (MAXI GP1) port to the Accelerator Coherency Port (ACP) or the High Performance(HP) port of the Zynq Processing system.

The Ethernet Packet Processing Unit has two AXI-4 slave interfaces as described below.

Control Port: This AXI-4 Slave interface provides access to all the control and status registers of the Packet Processing Unit. This port is connected t