With the continuous expansion of embedded system application fields and the increasing complexity of embedded systems themselves, the problems involved in embedded system design are also increasing, and the difficulty is also growing. How to choose a suitable design model based on actual needs is a problem that designers need to consider. This paper introduces two common embedded system design models and analyzes and compares these two models. 1 Introduction Today, embedded technology has become a new technological hotspot in the embedded field. The most typical characteristic of embedded systems is their close relationship with people's daily lives. From small micro-digital devices such as MP3 players and PDAs to large-scale information appliances, smart appliances, and vehicle GPS devices, the number of various electronic products and new embedded devices using embedded technology far exceeds that of general-purpose computers. In the more than 30-year history of embedded device development, embedded technology has never been as popular as it is now, and humans have never enjoyed the convenience brought by embedded technology as much as they do now. An embedded system is an application-centric, computer technology-based, customizable hardware and software system suitable for application systems with strict requirements on functionality, reliability, cost, size, and power consumption. From an overall perspective, we divide embedded systems into two parts: the first part is the application-related hardware platform, which is responsible for interacting with the external environment; the second part is the functional software running on this hardware platform. In recent years, the rapid development of microelectronics technology has significantly reduced the cost of hardware components, allowing many to implement parts that previously required software in hardware, blurring the lines between software and hardware. However, embedded system developers must design high-performance systems within the shortest timeframe and with the lowest cost. The most crucial step is dividing the entire system into hardware and software parts based on specific requirements. On general-purpose PC platforms, this hardware-software division is straightforward; however, on embedded platforms, many factors need to be considered. For example, to improve operating speed and reduce task switching costs, certain functions must be implemented in hardware. This paper focuses on two embedded system design models and analyzes and compares these two models. 2 Hardware-First Design Approach The hardware-first design approach, also known as the traditional system design approach, relies on sequential control flow. This approach begins with a requirements analysis of the entire system. Due to the specific nature of embedded systems, various aspects such as functionality, power consumption, and cost need careful consideration. After completing the requirements analysis, the next step is to divide the system into software and hardware parts. This step is very important. From this point on, the system will be divided into two parts: software and hardware. (1) The hardware part includes the system's hardware platform and some functional modules implemented with dedicated hardware (e.g., ASICs and Ip-cores); (2) The software part refers to the specially processed operating system and some functional modules built on top of the operating system. The second step is a very important step, which is usually done by the embedded system designer based on their experience and intuition. After this part is completed, the hardware design and implementation will be carried out. After the hardware part is available, the implementation of the software part can begin. The last step of this serialized design method is integration and testing, that is, merging the software and hardware parts together to evaluate the performance of the entire system. Figure 1 Hardware-first embedded design model Although the hardware-first design model has some problems (explained in detail in Part IV of the text), it is still a very popular solution. In some small and medium-complexity systems, this method is usually chosen because the hardware complexity is not high and the technology is relatively mature; however, in some large systems, this method is not very suitable and a more advanced design model is required. 3. Hardware-Software Co-design Methodology Hardware-software co-design, guided by system objectives, involves comprehensively analyzing the system's hardware and software functions and existing resources to maximize the concurrency between them and collaboratively design the hardware and software architecture to ensure the system operates at its optimal state. Essentially, it involves designing the software and hardware architecture as a whole in parallel, finding the optimal integration point so that they interact and combine most effectively, thus enabling the system to function optimally. The first step in this approach is to formally describe the system requirements. Several methods can be used, including Petri nets, data flow diagrams, and state machines. This design approach attempts to use these mathematical reasoning methods to provide a comprehensive description of the system's behavior. After formalizing the system description, it can be decomposed into functional modules, each implementing a part of the overall functionality. The functional modules obtained in the first step can be implemented using either hardware or software. Using formal methods, we can choose the optimal approach. During the hardware-software partitioning process, through evaluation of various aspects, such as time complexity and cost estimation, a set of optimal choices is obtained. After obtaining the optimal solution, the next step is to implement each module; however, this implementation is only theoretical. For example, hardware modules are described using VHDL, and software modules are represented using C or C++. Figure 2 shows the final step of the hardware-software co-design model: system integration. In this process, all modules are combined, and then it is verified whether the combination of these modules conforms to the formal specification of the system; if not, the hardware and software must be re-partitioned. One of the current research hotspots is the theoretical research on verification algorithms. Using these theoretical algorithms, the hardware-software partitioning and module verification can be fully automated. Since the hardware-software partitioning is based on theoretical algorithms, problems can be exposed as early as possible in the design process to reduce losses. However, this design model also has its limitations (explained in detail in Part IV of the paper). 4 Analysis and Comparison of the Two Models 4.1 Analysis of the Hardware-First Design Model The embedded system designed using the hardware-first method can only verify the correctness of the system design in the final step. Therefore, in the process of system development, the product is made to meet the design requirements by repeatedly modifying and testing. This largely depends on the designer's experience; moreover, the design cycle is long, the cost is high, and the product quality is difficult to guarantee. This is because in the process of repeated modification, it often deviates from the requirements of the original design in some aspects. Therefore, in order to reduce the design risk, the designer will choose to use the mature modules instead of redesigning them. At the same time, this design method has a major drawback: the software module cannot be implemented before the hardware part is available. Due to the above problems, the hardware-first design method is suitable for some small and medium-complexity systems. In these systems, the hardware complexity is not high and the technology is relatively mature. Therefore, this method is usually chosen. 4.2 Analysis of software and hardware co-design model In the software and hardware co-design model, since the division of software and hardware is based on theoretical algorithms, problems can be exposed as early as possible in the design to reduce losses. However, this design model also has its limitations, specifically: (1) Whether the available information is sufficient. If a formal method is to describe the entire system and correctly decompose the system into a combination of multiple functional modules, the designer needs to know the functional description of the entire system. However, for some third-party developed modules, the designer cannot know the internal functional implementation. This situation may lead to inaccuracy in the system partitioning process. (2) The degree of freedom of software and hardware modules to replace each other. In this design model, after the system is divided into software and hardware modules, it can be considered that each module can be converted to each other: that is, the module originally divided into hardware implementation can also be implemented by software, and vice versa. Theoretically, this is not a problem, but in practical applications, such a flexible theoretical level cannot be achieved. 4.3 Comprehensive comparison of the two models Generally speaking, embedded system design can be divided into four stages: system description, system design, system evaluation and comprehensive implementation. The two design models mentioned above have similarities and differences in these four stages: (1) In the system description stage, although both design methods fully describe the system functions, the software and hardware co-design method, in addition to fully describing the system functions, also deeply explores the synergy between software and hardware, so that the system can work stably and efficiently. (2) In the system design phase, both design methods will complete the allocation of hardware and software functions, that is, determine which functions are implemented by hardware modules and which system functions are implemented by software modules, as well as system mapping, that is, select and determine the system architecture based on the system description and function allocation. In the hardware and software function allocation phase, due to the programmability of hardware modules and the variability of embedded systems, the boundary between hardware and software is not very clear; therefore, the functional division of hardware and software is a complex and arduous process. This is partly because the research on hardware and software division is still in its early stages; and partly because of the inherent complexity of this problem. When allocating hardware and software functions, it is necessary to consider both the resources available in the market and factors such as system cost and development cycle. The hardware-first design method generally determines the hardware and software division based on the designer's experience, while the hardware and software co-design method uses formal methods to obtain a set of optimal choices through various evaluations, such as time complexity and cost estimation. In the system mapping stage, it is necessary to determine which hardware modules (such as microprocessors, microcontrollers, memory, FPGA, DSP, etc.), software modules (operating systems, drivers, etc.), and communication media between hardware and software modules (such as shared memory, buses, etc.) will be used in the system. In this stage, designers using the hardware-first design method usually choose to use mature hardware modules instead of redesigning them themselves in order to reduce design risks. Designers using the hardware-software co-design method need to design the software and hardware system as a whole in parallel and find the best combination point between hardware and software. This process is obviously a complex and arduous one, but this method can enable hardware and software to interact and combine in the most effective way, so that the system works in the best state. (3) In the system evaluation stage, it is the process of checking and confirming the correctness of the system design. Designers using the hardware-first method verify and evaluate the design results by repeatedly modifying and experimenting during the system development process, which largely depends on the designer's experience. Designers using the hardware-software co-design method use formal evaluation techniques to establish accurate mathematical models and use mathematical means to detect the correctness of the system. Therefore, it has a special effect on checking the uncertainties and implicit indicators in the system. (4) In the comprehensive implementation stage, that is, the specific manufacturing process of the software system and hardware system. The hardware-first design method implements the hardware part first, and then implements the software part after the hardware part is completed; while the software-hardware co-design method designs the software and hardware system as a whole in parallel, and through co-design, deeply explores the synergy between software and hardware, so that the designed system can work stably and efficiently. Through the above analysis and comparison, it can be seen that the hardware-first design method is suitable for some small and medium-complexity systems. In these systems, the hardware complexity is not high and the technology is relatively mature, so choosing this method is simple and easy to implement; however, in some large systems, this method is not very suitable, and a more advanced design model is needed. The software-hardware co-design model is more suitable for use in some large systems. In the design of some large systems, the designer's main task is to determine the functional modules, allocate system functions, establish the connection between modules, and specify the interaction between modules based on the system description. Compared with the hardware-first design model, the software-hardware co-design model can solve these problems more effectively. 5 Conclusion This paper introduces two design models for embedded system development: hardware-first and software-hardware co-design models. In the hardware-first design model, a hardware platform is designed first based on specific requirements, and then software development is carried out on this platform; typically, the hardware platform developers also need to provide the corresponding operating system. In another design model, theoretical algorithms can be used to verify the partitioned hardware and software modules. Of course, neither model is perfect; they each have their own advantages and disadvantages. Appropriate selection needs to be made based on actual application requirements to design a suitable embedded system that meets those needs.