Software Driven Test of FPGA Prototype

Most everyone would agree how important FPGA prototyping is to test and validate an IP, sub-system, or a complete SoC design. Before the design is taped-out it can be validated at speeds near real operating conditions with physical peripherals and devices connected to it instead of simulation models. At the same time, these designs are not purely hardware, but these days incorporate a significant amount of the software stack and so co-verification of hardware and software is put at high importance among other requirements in the verification plan.

However, preparing a robust FPGA prototype is not a trivial task. It requires strong hardware skills and spending a lot of time in the lab to configure and interconnect all required peripheral devices with an FPGA base board. Even more difficult is to create a comprehensive test scenario which contains procedures to configure various peripherals. Programming hundreds of registers in proper sequence and then reacting on events, interrupts, and checking status registers is a complex process. The task which is straightforward during simulation, where full control over design is assured, becomes extremely hard to implement in an FPGA prototype. Facing this challenge, verification engineers often connect a microprocessor or microcontroller daughter card to the main FPGA board. The IP or SoC subsystem you are designing will be connected with some kind of CPU anyhow, so this way seems natural. Having a CPU connected to the design implemented in an FPGA facilitates creating programmatically reconfigurable test scenarios and enables test automation. Moreover, the work of software developers can be now reused as the software stack with device drivers can become a part of the initialization procedure in the hardware test.. The software can become a part of the initialization procedure in the hardware test. If that makes sense to you, then why not use an FPGA board that has all you need - both FPGA and the CPU?

Recently Aldec announced availability of a new FPGA prototyping board featuring the largest Xilinx® UltraScale® XCVU440 FPGA connected with the Xilinx Zynq®-7000 XC7Z100 that can be used as a host and test controller. The XC7Z100 chip is the largest of the Zynq-7000 family and it combines the dual-core ARM® Cortex®-A9 with programmable FPGA fabric. This way Aldec has addressed the needs of many designers and verification engineers who demanded a compact and self-contained FPGA platform to implement software driven embedded testbenches. You can take a look at the board features and specification on the Aldec’s website here HES-US-440.

Figure 1. Aldec HES-US-440 FPGA Prototyping Board

For the time being, let me show how you can use this board to create the software driven testbenches.

The first question you might have would be: “What are the interconnections between the UltraScale and Zynq devices?” A glimpse at the block diagram shows that there are 160 traces interconnecting regular FPGA I/Os that can be used as LVDS (80 pairs) and there are also 4 GTX high speed serial links. Additionally, there are many standard interfaces already connected to each FPGA. By using a loopback cable you can add PCIe, USB, or Gigabit Ethernet links between the two Xilinx devices. Finally, there are 3 FMC connectors connected to the UltraScale and one connected to the Zynq. Although their primary function is to provide connectivity for expansion daughter cards, they also can be used to increase number of I/Os between both FPGAs.

Figure 2. Aldec HES-US-440 Connection Diagram

Bare-metal programmed testbench

The regular inter-FPGA I/O connections available on this board are sufficient to implement a very common test case with an AMBA AXI local bus being bridged between the two devices using the Xilinx AXI Chip2Chip Bridge. Xilinx Vivado provides all means to configure the AXI Chip2Chip module and integrate it with the ARM Cortex Programmable System in the Zynq device with the Design Under Test (DUT) in the Virtex UltraScale device. The SelectIO LVDS PHY may be configured to provide physical connections. This way the ARM core gets access to the memory mapped slave interface (S) of your DUT, so it will be able to execute bus read and write transfers. Similarly, your DUT’s AXI master interface (M) can access memory mapped devices of the Zynq Programmable System, for example the DUT can read and write data to/from the same DDR memory being used by the ARM CPU. I’m sure you already have a handful of ideas and scenarios for your testbench if you were given such functionality.

Figure 3. Bare-metal application driving the DUT

That’s all on the hardware side. Simultaneously the Xilinx SDK (Software Development Kit) tool generates the software application layer that matches the hardware configuration described above. The generated API allows you to handle AXI transactions in the memory space of your DUT with a simple C function call. There is nothing more needed to start developing your bare-metal embedded testbench.

Testbench app executed in embedded operating system

The bare-metal approach described above provides great flexibility for the testbench configuration and enables use of various hardware resources directly by the testbench. There are, however, cases where the user is only interested in performing AXI read/write operations to the DUT port and it is more important to bring up different test cases fast without worrying about underlying hardware configuration. For such users Aldec provides preconfigured implementations of the Zynq device that is optimized to run an embedded Linux operating system. The Linux controls standard peripherals connected to the Zynq device like Ethernet or USB. With such interfaces being up and running the board can be made available on-line in the corporate LAN and you can start testing your design without spending a minute in a noisy lab. In order to create a testbench you can use either a user-level C API or an exemplary application that reads AXI read/write commands from files or receives them from the Ethernet socket.

On the hardware side you simply connect your DUT with the Proto-AXI module that is provided by Aldec which implements connectivity with the embedded testbench running in Zynq.

Figure 4. Embedded system driving the DUT

Summary

The design landscape is changing rapidly through the ever increasing amount of embedded software that is crucial to the operation of heterogeneous multi-processor designs. In parallel, the design verification methodologies are more and more dependent on software. It is wise to reuse as much of software developers work as possible to verify the hardware.

The software driven verification methodology may significantly shorten your schedules especially if it is moved from simulation to an FPGA prototyping environment. The main obstacle in deploying FPGA hardware for verification is its setup and maintenance complexity. This is the reason why Aldec has developed the integrated solution that provides both a programmable ARM core and the largest Xilinx UltraScale FPGA on a single board. To make the software driven verification even easier Aldec provides sample designs for bare-metal and embedded-linux driven testbenches.