Embedded software and hardware interface design example

RF cable can be customized for other specifications

In embedded system design, software and hardware interface issues often plague software development engineers. A proper understanding of the constraints of the interface in the processor and high-level language development environment can accelerate the overall system design and provide guarantees for improving the quality, performance and reliability of the system, as well as shortening the development cycle and reducing costs. The comparison begins with the design principles of embedded systems and various considerations regarding registers and their fields.

Embedded system design is usually divided into two parts: hardware design and software development. These two tasks are usually handled by different design teams with little coverage. Since the software team rarely gets involved in the previous hardware design, development in this way often encounters problems, especially when the interface performance between the hardware and the software development environment is poor, which leads to prolonged system development time and increased development cost. Eventually delay the launch of the product.

The ideal solution is for the software team to participate in hardware design, but it is often impractical in terms of scheduling, funding, and people. One workaround is to create a set of hardware interface specifications to speed up the software development process. Understanding the optimized hardware interface design from the perspective of the software developer can effectively prevent unnecessary hardware problems in software development, and this method has little impact on the hardware design process.

General model of embedded system architecture

From a system perspective, an embedded system is a collection of interfaces between various system elements. The main resource listed here is the system processor. The processor interfaces can be divided into two broad categories, identified as local bus and hardware bus. It is worth noting that the bus in this article is defined separately according to the access type when the processor utilizes resources, and has no corresponding relationship with the specific hardware connection.

The local bus is the interface bus between the resource and the processor, which allows unlimited continuous access. Unrestricted access means that the processor can access all elements of a resource using its internal data types (such as bytes, words, and double words); continuous access means that all resource elements occupy a contiguous resource address space with no gaps in between. . RAM and EPROM are common examples of interfaces to local buses.

Hardware bus connections to resources often have certain limitations, such as size, location, addressing, address space, or relocation. I/O ports that only accept word writes, or peripheral chips on the PCI bus that must be mapped before use are some examples of hardware bus interfaces. The use of hardware bus connections has limited limitations for software design engineers to access resources, potentially creating complex code and code errors during software design, development, and integration.

The right hardware bus interface design speeds up the software design process and often speeds up hardware verification. This article focuses on the design and implementation of a hardware bus connected to programmable logic resources.

System-defined instance

Consider two different hardware implementations here. The system is a processor-controlled three-axis servo system. The system design in this part is limited to the design of position feedback control, which helps us to focus on the implementation of the hardware interface.

Both implementations of the system implement an interface between the processor and the user's ASIC (or FPGA) to provide drive and feedback information for the three-axis servo. The ASIC in each system must utilize a 32-bit data bus to connect the processor to three sets of drive/feedback resources. Each resource contains a signed 10-bit drive register, a signed 8-bit position register, and a 3-bit error status register. Any position bit indicates an error condition, which generates the axis drive (axis drive) ) Closed information.

Figures 1 and 2 show possible implementations of a register interface, identified as System Implementation A and System Implementation B, respectively. For convenience of description, the two implementations are referred to by System A and System B, respectively.

When implemented in VHDL (or other advanced hardware design methods), the design complexity of the two hardware interfaces is almost equal. System A appears to be slightly more efficient because its register address decoding is relatively simple and uses less hardware than System B. To reduce the number of logic cells in a programmable device that interfaces with the processor, most hardware design engineers choose the implementation of System A.

The pseudo-random code shown in Table 1 is an axis driver and can be used in both A and B systems. The pseudo-random code is designed for implementation on an advanced processor-based system and runs on a real-time operating system that implements axis control with three independent mussels (or task instances) of the universal axis control program. Only those lines with an asterisk in the pseudo-random code are required when using the interface defined in System A.

Obviously, even in the code prototype phase, System B requires much less code than System A. The hardware design in System B is slightly more complicated, but it can ease the burden of software development. These two example systems and pseudo-random codes will be reviewed later.

At the time of this writing, hardware design engineers may have this problem: "Why is the first design less efficient than the second?". The parameters for controlling the axial operation of the two implementations are the same, and the number of programmable hardware devices required by the first method is obviously less than the second. In order to answer this question correctly, the design engineer must look at the design from a system perspective, rather than the "logic gate" angle that hardware design engineers are accustomed to. The next section will describe some of the concepts that hardware design engineers often encounter when developing system hardware interfaces. These techniques will be discussed further and the results of applying these concepts to the example system design will be examined.

In order to meet the project requirements, the optimization of the entire system structure requires a compromise between hardware and software implementation. In reality, no project can meet all the ideal software interface requirements mentioned here. An understanding of the ideal state helps hardware design engineers identify and eliminate some of the barriers that affect software design.

Design Principles

1. Using standard bus access

The general principle of effective embedded hardware interface design is that for software design engineers, the hardware design should ensure that access to hardware resources is as transparent as possible. The processor uses all standard read and write instructions for transparent access, regardless of previous access content or timing.

Such as page register settings, write data encoding on address lines, etc. can seriously affect the development of the code, and often need to develop a driver that converts between standard access and the required special access.

It is usually inevitable to use some special buses, but you need to carefully consider the choice of special access space, because this situation will bring some difficulties to the system software design. System A uses write-only registers, so the system software is required to provide "shadow" memory (Shadow memory) to hold the data written to the resource. System B does not have this limitation because it allows all registers to be readable and writable.

2. Develop a processor-based resource interface

Hardware design engineers are accustomed to analyzing resource interface issues and connections to the system bus from the bottom up, while analyzing the processor's access to resources in the system is better.

The interface between "processor and resource" is often the most important interface, and its efficiency should be the top priority in the hardware design flow. Unified planning of resource access throughout the system is important to properly understand access restrictions caused by hardware design choices.

The most advanced systems available include a memory controller and a remappable bus that change the type of access between the processor and the resource interface. In general, an unqualified hardware interface design is not possible to reflect before the software team tries to connect to the actual resources, which is important for designing hardware interfaces.

3. Creation and maintenance of system memory map

For a good system design, the memory mapping of all resources is very important. As mentioned earlier, the design of the memory map should take into account the specific processor requirements, rather than simply specifying the type of address line that a resource decodes. If a register configurable resource is used, such as a PCI bus, the hardware design engineer should configure all configuration registers associated with the resource in the memory map and provide configuration register initialization values ​​to create the static maps required for hardware verification.

Hardware design engineers must also carefully consider the advantages of dynamic reconfiguration. A system that does not have new (or reduced) resources on the reconfigurable bus can evolve into a static map by forcing the configuration registers to revert to the same value after a system reset. This "static" system diagram provides a stable, unified structure for hardware integration and software development, while avoiding the use of error-prone pointer operations in system code.

Finally, as the system matures, memory mapping must continue to improve and evolve as software and hardware development progresses.

4. Unified access mode

Due to the increased complexity of current embedded systems, it is usually designed by many people working together. The design of each hardware component must be consistent with the whole in order to develop a unified resource access model. If access to different functional modules is inconsistent, potential access restriction errors can occur during software development, which may require the design of specialized software drivers for each subsystem. Inconsistent access to different logical blocks can also make hardware integration and verification difficult.

For example, a design engineer editing four hexadecimal digits on the debugger does not guarantee that the processor will use a 16-bit read/write cycle. Therefore, using the debug tool to set up multiple types of restricted access in software development and hardware integration. It also has certain difficulties. In this way, it is useful to evaluate the ability of the emulator to handle multiple restricted access address spaces, especially in processor architectures that use a "restricted" access mode to trigger a bus fault.

Register design

Now that the focus of hardware design engineers has shifted from logic gates and buses to system design, let's examine the most commonly used register designs for any processor system. The register interface allows high-speed access to resources, and the efficiency of their access has a large impact on system performance.