System Controller Manufacturing Test (Part 1)

The Hardware

In his November article, Nishant Mittal discussed ways of various ways of testing a board. In this two-part series, Nishant expands on that topic, this time discussing the design of an FPGA-based system controller built for testing and managing complex platforms. Part 1 focuses on the hardware aspect of the system, including the hardware design, building blocks, algorithm and so on.

A “system controller” can be defined as a system on a board or a platform capable of managing, controlling and monitoring the entire platform—right from power to communication. A system controller can be used not only to manage a platform, but also to test the peripherals of the platform, which reduces the cost of manufacturing test.

As electronic devices become more complex, the platforms for these devices also have become huge. Test coverage of the entire board for various features can become difficult especially when it’s a SoC that has multiple peripherals with different power controls on it. Such types of systems require an equally competent controller onboard that can easily manage and control the entire set of knobs. In my article “Designing Manufacturing Test Systems” (Circuit Cellar 352, November 2019) I discussed, various ways of testing a board. In this article, we will discuss one aspect of that with a system controller on board. All that said, much of this article will focus on the management of knobs and monitoring the system.

After the initial development, this can act as a “black box” and can sit on any other platform to perform different actions. This is presented in two parts to help readers understand how to design a system controller using Xilinx Zynq Ultrascale+ FPGAs and Xilinx tool chains. Here, we’ll discuss the hardware aspects of the system including the design, the building blocks, the algorithm and so on. In Part 2, coming next month, I’ll discuss the software and firmware of the project as a part of complete system integration.

DESIGN STEPS
Designing a system controller involves brainstorming from both a hardware and a software point of view. Figure 1 shows the block diagram of a generic system controller. A typical system controller needs a robust processor, a communication block, a memory block, a clock and a power management block. Any number of additional features could be added to this list.

FIGURE 1 – Typical block diagram of a system controller

As shown in Figure 1, we have used the Zynq Ultrascale+ FPGA as the central core of the system controller. The Zynq Ultrascale+ device is broadly divided into two parts: PL and PS. The PS part is the Arm processor while the PL part is Xilinx proprietary hardware block, which does actual FPGA related tasks. To understand details on how Zynq Ultrascale Plus device works, you can read the technical manual [1].

Ethernet is an essential part of the system controller because it helps to control the board from the distance location and enables you to work with the board remotely. UART is a critical element for debugging. The UART is an essential component because it enables you to work with the board locally by connecting the PC to the board via the FTDI circuitry of the UART using a USB Type-A or Type-B cable.

— ADVERTISMENT—

—Advertise Here—

The system controller we’re building here is designed to run Linux onboard. In other words, the system controller will be able to boot up Linux and have Linux perform all of the controller’s operations. In order to boot Linux—or to transfer any information to the Linux OS—we can use an SD card or an onboard EMMC drive that can boot the processor as well as store information.

Complex platforms bring with them the need to have multiple knobs to control. Power management and clock control are the major knobs to be controlled. Generally, these knobs are all I²C devices and can be connected to a single bus by adjusting the pull up resistors. Using the I²C mux, the number of devices per bus can also be increased. A number of GPIO banks are also necessary. These GPIOs help to provide enable/disable signals, control signals, control LED representations and so forth.

BRING OUT THE TOOLS
Now that the block diagram is defined, we now need to need to understand the overall system requirements and plan the design. To make this design possible, we made use of the PetaLinux tool from Xilinx to create a bootable image to be loaded which has Xilinx board support package. In Part 2 of this article, we’ll discuss PetaLinux and how to use it to create the bootable image. Once booted, the Linux system then probes all the devices and enables them. Apart from that, it will also perform power management and clock management using PMBUS protocol and I²C protocol.

Other miscellaneous items such as EEPROM, SPI LCD and GPIOs can all be controlled using standalone applications dumped in the system controller Linux image. All these software aspects will be discussed in detail in Part 2.

Once the overall mapping of the peripherals is done, it’s time to create the hardware design of the system controller using Xilinx’s Vivado tool. Vivado is a hardware design tool that lets you not only design own IP (intellectual property) blocks, but use existing IPs and connect the blocks using the interactive GUI. The tool can be used to create a “bit” file and an “hdf”—the hardware design file. These two files are necessary to create the Linux image using the file’s Xilinx Board Support Package information.

HARDWARE DESIGN
The Vivado tool gives users a visual representation of what the hardware looks like and how it’s going to map to the actual device. If you’re not already familiar with Vivado, we recommend you take a look at the Vivado the tool guide [2] before reading through this section.

When you first open the Vivado tool, a good first step is to drag and drop the Zynq Ultrascale+ processor into the drawing window. That processor is the heart of the project, which will connect to all the other peripherals. When you double click that processor block of the FPGA, you can see the overall block diagram of the FPGA. At this point, the entire device is reconfigurable. Given that power is a major concern, it’s always a good idea to enable only those blocks that are required for the design and disable the rest of the blocks. Doing that not only consumes less current but also reduces the compilation time. The more hardware you enable, the more time the software will take to create a netlist.

Figure 2 shows the block diagram of the Zynq MP block. Here, we enable Ethernet, SD, eMMC, UART I²C and GPIOs. You could also add Soft IP, which will then get routed through the AXI interface to the IP. Figure 3 shows the hardware design for the system controller that we talked about in the previous section. Here we have an AXI I²C block that comes from the PL side. We have an AXI interconnect in between that handles all the addressing and clocks—along with signaling to prevent data loss. Because most of the blocks are on the PS side (Figure 2), they won’t be visible in the front-end GUI of Vivado.

FIGURE 2 – Block diagram of the Zynq MP as seen from Vivado tool

FIGURE 3 – Front end of the hardware design in Vivado

Once this is done, we need to write the constraints for the design. These include specifying the clock max, assigning pins to the interfaces, setting the default state of the pins and so on. All that information goes into the .xdc file. Here is an example of some of the constraint properties:

— ADVERTISMENT—

—Advertise Here—

set_property PACKAGE_PIN AC14 [get_ports EMIO_GPIO_tri_io[0] ]
set_property PACKAGE_PIN AC13 [get_ports EMIO_GPIO_tri_io[1] ]
set_property PACKAGE_PIN AA13 [get_ports EMIO_GPIO_tri_io[2] ]
set_property PACKAGE_PIN AB13 [get_ports EMIO_GPIO_tri_io[3] ]
set_property PACKAGE_PIN AB15 [get_ports EMIO_GPIO_tri_io[4] ]
set_property PACKAGE_PIN AG13 [get_ports SYSCTLR_SI570_scl_io]
set_property PACKAGE_PIN AH13 [get_ports SYSCTLR_SI570_sda_io]

We see that AG13 and AH13 are declared as scl and sda for SI570 which is the clock frequency generator. AA13, AC13, AC14, AB13 and AB15 are declared as tristate GPIOs. Similarly, you can declare your own set of GPIOs based on the platform connections to the system controller. At this stage, the design is ready. Now it can be compiled to generate the .bit and .hdf files. If the design fails, you can use gate level synthesis to understand the reason for failure. That can root out anything from a timing violation to some messy connection. Now that the design is ready, the next step is to bring the design to life using various software tools. Note that system controller need not be present on the same platform board. It can be a separate board if desired, depending on the budget or other user requirements.

CONCLUSION
In this article, we explored the features of system controller and gained an understanding of how it can be useful from various design perspectives. We also learned how to design the hardware part of the system controller using the Vivado toolchain. In Part 2 next month, we’ll take a deep dive into the software side of the design, and look at how to bring alive the hardware we designed in this part.

RESOURCES

References:
[1] https://www.xilinx.com/support/documentation/data_sheets/ds891-zynq-ultrascale-plus-overview.pdf
[2] https://www.xilinx.com/products/design-tools/vivado.html#documentation

Xilinx | www.xilinx.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2020 #354 – Get a PDF of the issue

Keep up-to-date with our FREE Weekly Newsletter!	Don't miss out on upcoming issues of Circuit Cellar. Subscribe to Circuit Cellar Magazine Note: We’ve made the May 2020 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.
Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.