Challenges faced by the development of commercial microcomputer-based devices

Many of the current embedded devices are designed based on commercially available microcomputers. The design procedure is shown below as before.

1) Determine the CPU family.
2) Determine the installed capacity of memory (ROM/RAM) according to the program to be run.
3) Select the closest off-the-shelf microcomputer in terms of the installed peripheral modules to achieve the product's required specifications.
4) If the built-in memory does not have enough capacity, supplement it with an external memory.
5) If there are any missing peripheral functions, add FPGA to make up for them.

Compare this with the initial design steps.

3) It's changed a lot since then.

In commercial microcomputers that have been converted to SoC, the addresses and interrupt levels of the built-in peripheral modules are fixed, and in many cases there is no need to think about them at the time of design. After that, we will design other parts according to the hardware specifications of the microcomputer to be used. At first glance, it seems that device vendors have optimized their microcomputers, so if users use them as they are, design efficiency will improve, but is that really the case?

Every time I was involved in the design of a commercially available microcomputer-based product, I came to feel a number of questions (problems).

This time, I will explain two of them.

1. Comes with features you don't use

There are probably few people reading this article who are using all the peripheral modules built into the commercially available microcomputers they are actually using. Count the number of unused A/D (D/A) and general purpose I/O ports. In particular, I think there are many cases where analog systems are not used at all. (See Figure 2)

Figure 2 Commercial microcomputer with unused functions

Now remember the question I asked earlier. Components that are not included when designing for each function are included in commercially available microcomputers, even though they are not visible because they are packaged. It may be said that there is no difference in terms of cost, but if there was a lineup that included only the functions you wanted, you should be able to get it at a lower price.

Purchasing a device with unused functions = wasteful expense

Users of commercially available microcomputers seem to accept this formula without any other choice, and accept it (unconsciously?). If there is a block diagram or pin layout diagram in the hardware manual of the microcomputer you are using, please try to fill in the parts that are actually used. I think you can recognize the percentage of the unused part.

2. There is no degree of freedom in interrupts

User applications are infinitely different, and regardless of address assignment, interrupt levels should have different priorities from the system's point of view even if the same functions are used. However, the operating speed of CPUs has increased steadily, and in combination with a real-time OS, the processing of interrupt tasks has become interrupt generation = setting an event flag, and the priority judgment is now OS-dependent. We are seeing more and more products with fixed interrupt levels from the outside.

See Figure 3. This is a chronological representation of the program transition states when two interrupts occur during the execution of an application program. Assume that (1) and (2) are the timings of interrupt generation, and (2) is the interrupt that you want to prioritize in the system.

Fig. 3 Difference in interrupt response time

If the interrupt level of the commercially available microcomputer used is higher for factor (1) and the level cannot be changed, even if the interrupt for factor (2) occurs during the execution of the interrupt (1) task, interrupt (2) will continue until the process is completed. ) the execution of the task is awaited. On the other hand, if the interrupt level can be changed, the interrupt (2) task can be executed when the interrupt of factor (2) occurs even while the interrupt (1) task is being executed. can be finished.

Of course, there are microcomputers on the market that can change the interrupt level, and in today's world where the majority of embedded device development man-hours are being taken up by software, it is possible that talk that pokes into the corners of the nested box will only be smoked out. However, I think that the usability of the product is always reflected in whether or not we make things with this much thought in mind.

System designers are expected to realize their applications in the best possible way, and the vendor's mission is to provide solutions that meet those needs. With the required SoC, it is impossible to meet all of the diversifying user needs as the scope of application expands.

FPGA with built-in soft-core CPU as a means of solving problems

Now let's turn to the FPGA. Needless to say, FPGA is a device that "can incorporate as many functions as needed, when needed." The procedure for developing a system with a soft-core CPU mounted on the FPGA is shown below.

1) Decide on a CPU. (I don't have many options...)
2) Determine the installed capacity of memory (ROM/RAM) according to the program to be run.
3) Decide the FPGA device considering the CPU, built-in peripheral modules, memory capacity, etc.
4) Determine memory and peripheral address assignments.
5) When using interrupts (and DMA), determine the level (priority) for each factor.

Did you notice that it resembles the initial design procedure more than a commercial microcomputer? If we regard the soft-core CPU and peripheral modules as individual components, then it is only natural that the design method will be similar to the era of single functions/components. Furthermore, it means that all the problems that have arisen because it is a commercial microcomputer will be released. Since the degree of freedom increases, sufficient preliminary consideration is required for the design, but since we didn't do what we should have done, we just tackle it head-on.

In addition, if there are fixed operating parameters for peripheral modules, setting them with a development tool not only eliminates the need for software settings, but also reduces the logic scale by omitting the registers for setting parameters. I would like to add that

in conclusion

I hope you have understood the goodness of FPGA with built-in soft-core CPU. There are cases where commercially available microcontrollers meet the required specifications 100%, and it may be irrelevant to companies with sufficient capital to develop custom microcontrollers for their own use. However, 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."

Next time, we plan to explain Nios II, a representative soft-core CPU, from the user's point of view.