~Welcome to the world of soft-core CPU with infinite possibilities~

Click here for Mr. Asai's introduction and serial titles

 

If you have any questions, please contact Mr. Asai at the address below.

Introduction

Last time, I talked about issues with commercial microcomputers and soft-core CPUs as a solution to those issues. This time, I will explain how to design CPU-mounted FPGAs and how Altera tools support Nios® II.

 

Design flow of FPGA with soft-core CPU

Figure 1 shows the design flow of an FPGA with a soft-core CPU. When viewed from the perspective of the entire device, the design target is divided into two steps: the inside and outside of the CPU-equipped module. The color coding corresponds to the design tools described below. In the case of commercially available CPU-IP, the flow may differ, so please consider adopting a CPU made by an FPGA device vendor that supports various tools this time. The following explanations are given in the order shown in the figure.

Fig. 1 Design flow of FPGA with soft-core CPU

 

On-Chip bus connection user module design

You may get the impression that we have suddenly entered into a deep discussion, but it is a simple story of "designing so that the user module is directly connected to the on-chip CPU bus in the high-level block-level design."

 

Soft-core CPUs made by FPGA device vendors are provided not only with the CPU itself, but also with peripheral modules such as timers, I/O ports, and external memory interfaces that can be directly connected to the On-Chip bus in advance.

 

Combining these is sufficient for general purposes, but those who aim for a "user-oriented SoC" using FPGA will probably want to incorporate user modules via On-Chip bus connections.

 

Tools from FPGA device vendors also naturally support On-Chip bus connections for user modules, so if you understand the specifications of the connection signals, it should not be difficult to incorporate for general usage. The general usage here indicates that the designed user module is a slave module (no bus master function) that is only accessed by the CPU, and the access is also simple asynchronous read/write. . On-Chip buses from FPGA device vendors have been devised in various ways to improve system performance. It requires knowledge and some experience.

 

To be honest, I do not recommend using the On-Chip bus user module for those who are new to soft-core CPUs.

The reason for this is that using various new functions in situations where you are unfamiliar with the tool may require a lot of time to analyze the cause when a problem occurs. First of all, I think one of the tricks to get up and running early is to get used to it in a range that minimizes uncertainties as much as possible.

 

CPU-mounted module design

Design a module with a CPU using the tools provided by the FPGA device vendor, with or without the aforementioned user module. The actual work is to set the parameters specific to each CPU and peripheral module and the settings required for inter-module connection and incorporate them one module at a time. The ease of use of this tool, which is positioned exclusively for mounting CPUs (in a broad sense, bus master + On-Chip bus), affects design efficiency, so each company is devising ways to do so.

 

Top module design

As will be explained later, design tools for CPU-mounted modules output their own top-level hierarchy, including peripheral modules, in HDL (Hardware Description Language), so that description can be used as-is as the top-level hierarchy for FPGA projects. can do.

 

However, depending on the application, modules that are not directly controlled by the CPU (not included in the flow in Figure 1) and IPs that cannot be directly connected to the On-Chip bus are often incorporated into the FPGA. In that case, you need to design the next higher hierarchy including the CPU module and other modules by yourself using HDL or circuit diagrams.

 

Now that HDL design is mainstream, is it too late to use a circuit diagram? You might think that.

 

Certainly, HDL-only design is effective for device-independent design, but it is unthinkable to be vendor-independent while using the soft-core CPU provided by the FPGA device vendor. In addition, I won't explain it this time because it's out of the essence, but it's better to design the top layer with a circuit diagram, so there are various advantages in the work that follows. Adding hierarchy to the diagram.

 

compile

Normal design work using tools provided by FPGA device vendors, such as logic synthesis, placement and routing, timing analysis, and configuration data creation.

 

software design

A CPU cannot function without software. Therefore, it is necessary to design the necessary software (initialization program, device driver, library, OS, middleware, application, etc.) according to the designed CPU module. Since most of the CPUs provided by FPGA device vendors are original designs, we provide a GNU (GNU is Not Unix)-based cross-development environment that runs on Windows and Linux operating systems.

 

Unlike commercial microcontrollers, in CPU-mounted FPGAs where memory and peripheral module address allocation and interrupts are arbitrary, it is necessary to prepare hardware-oriented software commonly called firmware, such as initialization programs and device drivers, for each design. I have. In other words, just like the ease of use of the CPU module design tool, the degree of support for software design, which is one-of-a-kind and cumbersome but indispensable for CPU modules designed by CPU users, is also a major decision factor in adopting a soft-core CPU. It is a translation.

 

Support for ICE (In Circuit Emulator) is also important. GNU-based debugging writes a monitor program called gdbstub to the ROM of the target. It is common to debug by communicating with the host PC via a serial port while using the CPU's software interrupt instructions (see Figure 2).

 

However, although this method is versatile, it has limitations, such as the fact that the software to be debugged must be in RAM in order to replace instructions, and that a dedicated serial port for debugging is required.

 

On the other hand, ICE, also called On-Chip Debugger, does not require a dedicated serial port because it communicates through the JTAG (Joint Test Action Group) port used for FPGA configuration (see Figure 3). Also, depending on the function of the On-Chip Debugger, it is possible to debug software that is executed on ROM, and it is possible to debug with the same resources as the final product.

 

Figure 2 Software debugging environment using gdbstub

 

Figure 3 Software debug environment using ICE

 

 

Design environment used when installing Nios II

Figure 4 shows the design environment used when installing Nios II. The color coding of each function corresponds to the flow in Figure 1. Quartus® II has many support functions for efficient design, and MegaWizard Plug-In Manager is a macro library management tool used when designing with schematics.

 

Since Nios II is a CPU, it requires not only hardware but also software design tools, and Altera provides all of them. The tools required for designing a Nios II-based FPGA are described below.

 

Figure 4 Nios II design environment

 

SOPC Builder

Nios II module design tool. It manages everything from Nios II, peripheral modules provided as standard, user module selection, address and interrupt level settings, and even automatically generates logic. It's been standard with Quartus II since a little while ago, so even if you know the name, there are probably many people who haven't started it because they don't use Nios II.

 

Figure 5 shows the SOPC Builder setup screen for the Cyclone II edition of the Nios II development kit currently on the market. The connection of each module is not shown due to screen limitations. Of course, when you start it for the first time, the design data part indicated by the blue line is empty, and you can call the function modules from the module list on the left side and add them while specifying the parameters unique to each module. For Nios II, CPU type (e/s/f), selection of debug module, memory resources for exception vector placement, etc. For slave modules, in addition to unique parameters, start address and necessary from Nios II Set the interrupt level accordingly. User modules for On-Chip bus connections created in the design flow can be handled in the same way as standard modules by registering them when the design is complete. After calling all the necessary function modules and setting them, the design is completed. After that, if you press the "Generate" button, all the modules including the CPU, the connection between modules, and the top-level description are specified in the specified HDL. output. Symbols that can be called by the Quartus II schematic editor are also output, making it possible to easily create top-level hierarchical schematics.

 

Figure 5 SOPC Builder Example (Nios II Development Kit Cyclone II Edition)

 

In addition, since information about modules incorporated for software design is also output, software design can be done efficiently.

 

Nios II IDE

It is a software development environment for Nios II, adopting Eclipse as the GUI, and has everything necessary for software design, such as compilers, debuggers, and standard libraries. Figure 6 shows the IDE screen when a project is created with the hello_world application template.

 

Figure 6 IDE screen (hello_world)

 

Software design will be explained in detail in the next issue, so I will limit myself to an introduction this time.

 

 

in conclusion

What do you think?

Did you understand how to design an FPGA with a soft-core CPU? Since it is a CPU, there is support for dedicated tools, but Nios II is also a kind of IP, so no special design method is required. Also, the tools made by Altera that I explained this time are included as standard regardless of whether they are the full-featured version or the free version, so you can try them out right away. For information on how to use each tool, please refer to the documentation provided by Altera, or ask the person in charge at the sales company. You can also get a development kit to easily evaluate the software using a sample design and get a product-loaded license.

 

For small and medium-sized mass-produced equipment manufacturers who cannot afford the ever-rising development costs, the combination of soft-core CPUs and FPGAs is "the only option that can realize a user-oriented SoC from a single minimum order."

 

In the next installment, we plan to introduce examples of hardware implementation.

 

→ next page

~ Soft-core CPU implementation example and its point (1) ~

 

Click here for introduction and serial titles of Mr. Asai