Method and system for simulating hardware communication protocol in virtual simulation environment

Abstract

The invention relates to the technical field of semiconductor manufacturing virtual simulation, and discloses a method and a system for simulating a hardware communication protocol. According to the scheme, asynchronous decoupling communication between the AMHS service and the machine service is achieved through the message queue (such as MQ), and a traditional hardware parallel I / O interaction mode is replaced. The method comprises the following steps of: defining a protocol format (such as a 16-bit binary number) of multi-bit signal packaging, and encoding signals such as VALID (Video Address Limit Identifier) and CS0 (Coding Sequence 0) into a single sequence message (such as hexadecimal '4030'); maintaining a predefined sequence list (an index corresponds to a communication step) and a latest sequence state; and checking whether a new message is matched with an expected sequence or not when receiving the new message, if so, updating the state propulsion process, otherwise, refusing and resetting. The system comprises an AMHS service, a machine service, a message queue component, a storage module and a verification module. According to the method, the problems of service dependence, bandwidth waste and sequence verification complexity in a virtual scene are solved, the simulation efficiency and fidelity are remarkably improved, and the method is suitable for interactive simulation of the AMHS and the machine of the semiconductor FAB factory.

Description

Technical Field

[0001] The present invention belongs to the field of communication technology, and in particular relates to a method and system for simulating hardware communication protocols in a virtual simulation environment. Background Art

[0002] In semiconductor wafer manufacturing, automated material handling systems (AMHS) use equipment such as overhead transporters (OHTs) to automatically transfer wafer carriers between machines. To verify the interaction logic between the AMHS and machine equipment (such as the load port), hardware communication protocols (such as the E84 standard) must be simulated in a virtual simulation environment. This protocol requires signal switching to follow a strict time sequence (for example, a load transfer involves 16 steps) and simultaneously transmits multiple signals (such as VALID, CS_0, and READY) via parallel I / O interfaces.

[0003] However, there is no relevant mature technology yet. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to address the deficiencies in the above-mentioned existing technologies and provide a method and system for simulating hardware communication protocols in a virtual simulation environment. While providing service decoupling, efficient transmission and dynamic sequence verification, it can accurately simulate the multi-bit parallel transmission characteristics of hardware communication protocols (such as the E84 standard) and improve the authenticity and robustness of virtual simulation.

[0005] A first aspect of the present invention discloses a method for simulating a hardware communication protocol in a virtual simulation environment, for simulating data exchange between an AMHS service and a machine service, the method comprising: Transmitting sequence messages between the AMHS service and the machine service via a message queue, wherein the message queue is an asynchronous communication mechanism to achieve decoupling between services; defining a protocol format that packages a plurality of signal bits into a single sequence message, each sequence message including a digital representation; Maintaining a state sequence, the state sequence comprising a predefined sequence list and a latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message; When a new sequence message is received, the new sequence message is checked to see if it matches the expected sequence based on the latest sequence state. If so, the latest sequence state is updated to proceed to the next communication step. If not, the new sequence message is rejected and the latest sequence state is reset.

[0006] In the above method, the protocol format is a binary format, the bit length is N bits, N is an integer and N≥8, and the digital representation is a hexadecimal or binary string.

[0007] The above method, wherein the signal bit includes at least one of the following: VALID, CS_0, CS_1, TR_REQ, L_REQ, U_REQ, READY, BUSY, COMPT, CONT, HO_AVBL, ES, VA, AM_AVBL, VS_0, VS_1, and each signal bit corresponds to a specific position in the protocol format.

[0008] The above method, wherein the message queue includes at least one of the following: MQ message queue, Kafka, RabbitMQ, pub / sub model or cloud-based message service.

[0009] The above method, wherein maintaining the state sequence includes storing the sequence list as a constant list in memory and accessing the sequence message by index.

[0010] The above method further comprises an error handling step of recording an error log or triggering an alarm when the new sequence message does not match.

[0011] A second aspect of the present invention discloses a system for simulating a hardware communication protocol, which is applied to a virtual simulation environment. The system comprises: AMHS service, configured to generate sequence messages; Machine service, configured to process sequence messages; A message queue component connects the AMHS service and the machine service and is used for asynchronous transmission of sequence messages; a storage module configured to maintain a state sequence, including a predefined sequence list and a latest sequence state, wherein an index of the sequence list corresponds to a communication step number and a value corresponds to an expected sequence message; The verification module is configured to verify whether a new sequence message matches an expected sequence based on the latest sequence state when it is received, and update the latest sequence state if it matches, and reject and reset it if it does not match.

[0012] The above system, wherein the protocol format is a 16-bit binary format, and each sequence message includes a hexadecimal representation.

[0013] In the above system, the storage module is an in-memory database or a distributed cache.

[0014] The above system, wherein the verification module is further configured to perform error handling when the sequences do not match, including generating a log or an alarm.

[0015] Compared with the prior art, the present invention has the following advantages: 1. Use message queues (such as MQ and Kafka) to implement asynchronous communication. AMHS services and machine services transmit messages through a publish-subscribe model without directly relying on each other's IP addresses or interfaces. This directly eliminates the direct interface calls and IP dependencies required when using HTTP or WebSocket. Services interact only through MQ proxies to achieve decoupling, thereby improving the system's scalability (for example, adding new services does not require reconfiguring dependencies) and maintainability (for example, service changes do not affect each other), which solves the defect of "strong coupling between services."

[0016] 2. By defining a protocol format, multiple signal bits (such as a 16-bit binary sequence) are packaged into a single sequence message (such as hexadecimal "4030"), and each message simultaneously transmits multiple signals (such as VALID, CS_0, etc.) without the need for additional identification fields. This simulates the advantage of hardware parallel I / O for simultaneous multi-bit transmission, significantly reducing the number of messages (for example, instead of sending multiple single-bit messages, one sequence message can now transmit all signals). Traditional single-bit messages waste bandwidth, while the packaging mechanism of the present invention optimizes bandwidth utilization and reduces transmission delay, which directly solves the problem of "low bandwidth utilization" and achieves efficient transmission of information data.

[0017] 3. By maintaining a state sequence (e.g., a sequence list stores the expected sequence of each step, and the latest sequence state variable stores the current step), the system dynamically verifies whether new messages match the expected sequence (e.g., by querying the sequence list based on the latest state index). If a match does not occur, the message is rejected and the state is reset. This solves the problem of traditional technologies requiring the storage of historical message sequences for complex verification (e.g., backtracking multiple steps). The mechanism of the present invention only requires a constant list and simple variables in memory, and performs real-time verification through dynamic matching (e.g., comparing the new message with the expected value of the corresponding step in the sequence list), eliminating the need to store historical messages. This simplifies verification logic (e.g., using if-else statements) and improves robustness (e.g., automatically resetting in the event of an error). This addresses the drawback of "high sequence verification complexity" and meets the requirement of "dynamic sequence verification."

[0018] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a flow chart of the method of Example 1.

[0020] Figure 2 This is the system architecture diagram of Example 2.

[0021] Figure 3 This is a diagram showing how the AMHS Service and EQP Service exchange Sequence contents through MQ.

[0022] Figure 4 The data structure for storing sequence lists in memory. DETAILED DESCRIPTION

[0023] Example 1: like Figure 1 As shown, a method for simulating a hardware communication protocol in a virtual simulation environment is used to simulate data exchange between an AMHS service and a machine service, the method comprising: Transmitting sequence messages between the AMHS service and the machine service via a message queue, wherein the message queue is an asynchronous communication mechanism to achieve decoupling between services; defining a protocol format that packages a plurality of signal bits into a single sequence message, each sequence message including a digital representation; Maintaining a state sequence, the state sequence comprising a predefined sequence list and a latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message; When a new sequence message is received, the new sequence message is checked to see if it matches the expected sequence based on the latest sequence state. If so, the latest sequence state is updated to proceed to the next communication step. If not, the new sequence message is rejected and the latest sequence state is reset.

[0024] It should be noted that service decoupling is achieved by asynchronously transmitting sequence messages between the AMHS service and the machine service through message queues. A protocol format is defined to package multiple signal bits into a single sequence message (such as a digital representation). A state sequence (including a list of predefined sequences and the latest sequence state) is maintained to verify the order of new messages. The state is updated or reset based on the verification results. This solves the problems of service coupling and bandwidth waste.

[0025] Achievable effects include: (1) Service decoupling: AMHS and machine services run independently without knowing each other's IP or interface, improving system scalability and maintainability; (2) Efficient transmission: Packing multiple signal bits reduces the number of messages and saves bandwidth; (3) Reliable sequence checking: Dynamically matching expected sequences to ensure strict order of communication protocols (such as E84) and avoid error propagation; (4) Overall simulation fidelity is improved, making it closer to real hardware interaction.

[0026] During implementation, those skilled in the art can design the following steps: Define the protocol format: The protocol format is a fixed-bit-length binary sequence (e.g., 16 bits), with each bit corresponding to a signal (e.g., bit 0 corresponds to the VALID signal). Sequence messages are represented numerically (e.g., hexadecimal "4030") for ease of transmission and storage. For example, in signal transfer step ①, the AMHS service packages multiple signal bits (e.g., CS_0 = 1, VALID = 0, etc.) to generate the sequence "4030." The message format is "EQP01-LP1-4030," where "EQP01" is the machine ID, "LP1" is the port number, and "4030" is the sequence value.

[0027] Use message queues as a transport: Choose an MQ implementation (such as RabbitMQ). The AMHS service acts as a producer, publishing sequence messages to an MQ topic (e.g., "amhs_to_eqp"). The machine service, acting as a consumer, subscribes to this topic and asynchronously receives messages. Similarly, the machine service publishes response messages to another topic (e.g., "eqp_to_amhs"). This way, services communicate directly with each other, using the MQ broker instead of directly invoking each other.

[0028] Maintaining state sequence: Create two data structures in the service memory: (1) sequence list: an array or list constant, indexed by the communication step number (step 0 to 15), with the value being the expected sequence message (e.g., step 1 corresponds to "4030", step 2 corresponds to "C030"); (2) latest sequence state: a variable that stores the current step number and the latest sequence (e.g., initially step 0). For example, in Java, you can use Map<T> to store the state of the current sequence.<Integer, String> Stores a sequence list, where the key is the step number and the value is the sequence string.

[0029] Verification and update status: When a new sequence message (such as "C030") is received, the current step (such as step 1) is obtained from the latest sequence status, and the sequence list is queried to obtain the next expected sequence (step 2 should be "C030"). If it matches, the latest sequence status is updated to step 2; if it does not match (such as receiving "4030" but expecting "C030"), the message is rejected and the status is reset to the initial step 0. Resetting may include clearing memory variables to ensure that the system restarts from a safe state. For example: In the semiconductor Fab virtual simulation, the AMHS service simulates the movement of the overhead crane, and the machine service simulates the response of the machine. For example, during loading and transfer, the AMHS sends the step 1 message "4030", updates the status after the machine verification passes, and sends the step 2 response. Those skilled in the art can use common programming languages ​​(such as Python or Java) to implement it without the need for complex algorithms.

[0030] It should be noted that the present invention provides an implementation of E84 in a virtual scenario. MQ (MessageQueue) is used to decouple the communication between the AHMS service and the machine, eliminating the need for mutual dependence on specific services. The protocol content includes 16 bits, as shown in Table 1. The signal bit allocation is as follows:

[0031] Using the bit allocation in Table 1, the signal sequence corresponding to the step is shown in Table 2. Table 2 is:

[0032] In this embodiment, the protocol format is a binary format, the bit length is N bits, N is an integer and N≥8, and the number is represented as a hexadecimal or binary string.

[0033] It's important to note that by limiting the protocol format to binary, with a bit length of at least 8 bits (e.g., 16 bits), and using hexadecimal or binary strings for digital representation, data representation can be optimized, enhancing readability and transmission efficiency. Hexadecimal strings (e.g., "4030") are more concise than binary, reducing parsing overhead; binary strings (e.g., "0100000000110000") facilitate bit manipulation, ensuring precise control of signal bits.

[0034] During implementation, the bit length N is set to a fixed value (e.g., 16 bits) to meet the E84 protocol signal requirements. For example: Binary format design: Each sequence message is represented using N bits of binary data, with signal bits mapped to specific positions (e.g., bit 0 is VALID). Those skilled in the art can implement this using bitmask techniques: define signal bit constants (e.g., VALID_MASK = 0x0001) and use bitwise operations to set or read signal values. For example, when generating a sequence, the AMHS service sets the corresponding bit based on the signal state (e.g., VALID = 1), which is then converted to the hexadecimal string "4030" for transmission.

[0035] Digital Representation Processing: After receiving a message, the hexadecimal or binary string is parsed and converted back to a binary sequence. For example, when the machine service receives "4030," it first converts it to an integer and then uses bitwise operations to extract the signal bits. Those skilled in the art can use standard library functions (such as Python's int(hex_str, 16)) to perform this conversion without the need for custom code. For example, in the virtual machine service, after receiving the message "C030," it converts it to binary "1100000000110000," then checks whether bit 1 (CS_0) is 1 to verify the assigned port. This simplifies signal processing and makes implementation more intuitive.

[0036] In this embodiment, the signal bit includes at least one of the following: VALID, CS_0, CS_1, TR_REQ, L_REQ, U_REQ, READY, BUSY, COMPT, CONT, HO_AVBL, ES, VA, AM_AVBL, VS_0, VS_1, and each signal bit corresponds to a specific position in the protocol format.

[0037] It should be noted that by enumerating specific signal bit types (such as VALID, CS_0, etc.), each bit occupies a fixed position in the protocol format, ensuring that the protocol is compatible with hardware standards (such as E84). Each signal bit has a clear definition, which improves the accuracy and versatility of the simulation.

[0038] When implemented, the signal bits are arranged in a predefined order in a binary sequence. For example: Signal bit mapping: Create a mapping table (used as a constant dictionary in the code) with the key being the signal name and the value being the bit index (e.g., VALID corresponds to bit 0, CS_0 corresponds to bit 1). When generating a sequence, set the corresponding bit based on the signal state (Boolean value). For example, in step 1, the AMHS service sets CS_0 to 1 and VALID to 0, generating the sequence "4030."

[0039] Positional immutability: Signal bit order is immutable, ensuring consistency across services. Those skilled in the art can use an array to store bit values, with indices 0 to 15 corresponding to each signal. For example, during a service check on a machine, the value of bit 1 (CS_0) is extracted from the sequence to verify that it is in the expected state. For example, during an uninstall step, the U_REQ signal (bit 5) is set to 1, and the remaining bits are adjusted according to the protocol. This simplifies implementation, as developers only need to maintain a single signal bit definition file.

[0040] In this embodiment, the message queue includes at least one of the following: MQ message queue, Kafka, RabbitMQ, pub / sub model or cloud-based message service.

[0041] The ability to choose a specific implementation of a message queue, such as RabbitMQ or Kafka, provides flexibility and adapts to different deployment environments (such as local or cloud), ensuring the versatility and scalability of the decoupling mechanism.

[0042] When implementing, choose any MQ system to configure the publish-subscribe model. Figure 3 As shown, for example: Set up a message queue: When using RabbitMQ, install the MQ server and create an exchange and queue. The AMHS service acts as a producer and calls an MQ client library (such as pika for Python) to publish messages to the topic "amhs_signals." The machine service subscribes to this topic and listens for messages. Similarly, you can use Kafka, create a topic, and configure a consumer group.

[0043] Cloud service integration: If cloud-based (such as AWS SQS), use the SDK to send and receive messages. Message format remains as a string (e.g., "EQP01-LP1-4030"). Technical personnel do not need to modify the core logic; they only need to adapt the MQ client initialization code. For example, in a test environment, RabbitMQ can be used to simulate communication: the AMHS service publishes a message, the MQ broker forwards it, and the machine service asynchronously receives and processes it. During implementation, developers can refer to the official MQ documentation for quick integration.

[0044] In this embodiment, maintaining the state sequence includes storing the sequence list as a constant list in the memory, such as Figure 4 As shown, the sequence message is accessed by index.

[0045] By storing the sequence list of the state sequence in memory as a constant and accessing it through an index (communication step number), the sequence verification can be simplified, the access speed can be improved (memory operations are faster than databases), the storage overhead can be reduced, and real-time performance can be ensured.

[0046] When implemented, initialize the sequence list as a read-only constant when the service starts: Data structure design: Use arrays or lists to store sequence values, with indexes starting at 0 and corresponding to step numbers. For example, define a list called seqList = ["4030", "C030", ...], where seqList[0] corresponds to the expected sequence for step 1. The latest sequence state is stored in variables such as currentStep (current step index) and lastSequence (latest sequence value).

[0047] Access mechanism: When checking for a new message, query seqList using the currentStep index to obtain the expected sequence. For example, when currentStep = 1, the expected sequence is seqList[1]="C030". If a match is found, currentStep++ is updated. Those skilled in the art can implement this using simple data structures, such as list and int variables in Python.

[0048] For example, in the AMHS service, seqList is initialized to ["4030", "C030", "C830",...]. When a message is received, the new message is compared with seqList[currentStep]. If a match occurs, currentStep is increased by 1. When resetting, currentStep is set to 0. This implementation is easy to understand and avoids complex databases.

[0049] In this embodiment, when the new sequence message does not match, an error handling step is further included: recording an error log or triggering an alarm.

[0050] By adding error handling, such as logging or alerting, when mismatches occur, system robustness can be enhanced, troubleshooting and maintenance can be facilitated, and error states can be prevented from propagating.

[0051] When implemented, execute after verification fails: Error handling logic: If there is a mismatch, the logging module is called to record the error (e.g., message content, expected sequence, and timestamp), or an alert is triggered (e.g., sending a notification to a monitoring system). Logs can be written to files or databases; alerts can be sent via email or API calls.

[0052] Reset Integration: Resets the latest sequence state (e.g., sets currentStep to 0) and then performs error handling. This can be implemented by a standard logging library (e.g., log4j) without requiring additional hardware.

[0053] For example, when a machine service receives an invalid message "0000," it logs "Invalid sequence at step 1, expected C030," resets the status, and sends an alert to the administrator. Implementation is simple; developers only need to add a few lines of error handling code.

[0054] Example 2: like Figure 2 As shown, a system for simulating hardware communication protocols is applied to a virtual simulation environment, and the system includes: AMHS service, configured to generate sequence messages; Machine service, configured to process sequence messages; A message queue component connects the AMHS service and the machine service and is used for asynchronous transmission of sequence messages; a storage module configured to maintain a state sequence, including a predefined sequence list and a latest sequence state, wherein an index of the sequence list corresponds to a communication step number and a value corresponds to an expected sequence message; The verification module is configured to verify whether a new sequence message matches an expected sequence based on the latest sequence state when it is received, and update the latest sequence state if it matches, and reject and reset it if it does not match.

[0055] It should be noted that the method of simulating hardware communication protocols in a virtual simulation environment described in Example 2 is essentially the same as that described in Example 1, but is implemented in a system form to provide an integrated solution that can achieve efficient decoupling, sequence assurance, and improved simulation fidelity, while being easy to deploy and maintain.

[0056] During implementation, those skilled in the art may deploy it as a distributed system, as follows: Component connection: The AMHS service (running in the crane simulator) connects to the machine service (running in the machine simulator) through a message queue component (such as a RabbitMQ server). The storage module (such as a Redis in-memory database) and the verification module are integrated into the service.

[0057] Module Functionality: The AMHS service generates sequence messages (such as packet signal bits) and publishes them to MQ. The machine service subscribes to MQ to receive messages. The storage module maintains the sequence list and the latest status (in memory). The verification module implements verification logic within the machine service (comparing the new message with the expected one). For example, the verification module uses if-else statements to determine the match and update the storage module status.

[0058] For example, in a virtual fab system, the AMHS service sends a message to MQ, and the machine service listens to MQ. Upon receiving the message, the validation module accesses the sequence list in the storage module and decides whether to update the status. Developers can implement each module using a microservices architecture (such as Spring Boot).

[0059] In this embodiment, the protocol format is a 16-bit binary format, and each sequence message includes a hexadecimal representation.

[0060] When implemented, the fixed bit length is 16 bits: The formatting is as follows: When generating a sequence message, the AMHS service converts the 16-bit binary string into a 4-character hexadecimal string (e.g., "0100000000110000" in binary format is converted to "4030"). Upon receipt, the machine service performs the reverse conversion. Those skilled in the art can implement this using built-in functions (such as Java's Integer.toHexString()) without requiring an algorithm. For example, the storage module stores the sequence list as ["4030", "C030"], and the verification module compares the string equality. This straightforward implementation avoids the complexity of bitwise operations.

[0061] In this embodiment, the storage module is a memory database or a distributed cache.

[0062] Implementation: If Redis is used, install a Redis server. In the code, use the client library to store the sequence list (as a hash) and the latest state (as a key-value pair). For example, the key "currentStep" stores the current step number. If the system is deployed on multiple nodes, use a distributed cache to synchronize the state. Those skilled in the art only need to initialize the storage client without modifying the core logic. For example, in a cloud environment, use Redis to store the state; the validation module reads the sequence list in Redis for validation. Developers can refer to the storage system documentation for quick integration.

[0063] In this embodiment, the verification module is further configured to perform error handling when the sequences do not match, including generating a log or an alarm.

[0064] When implementing, the validation module adds error handling logic: When a mismatch occurs, the verification module calls a logging API to record error details or triggers an alert service (such as a Slack notification) via an API. For example, if verification fails, the verification module writes a "Sequence mismatch error" message to the log file and resets the storage module status. Those skilled in the art can implement this using existing logging frameworks, such as Python's logging module.

[0065] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any way. Any simple modification, change and equivalent structural change made to the above embodiment based on the technical essence of the present invention shall still fall within the scope of protection of the technical solution of the present invention.

Claims

1. A method for simulating a hardware communication protocol in a virtual simulation environment, characterized in that: For simulating data exchange between AMHS service and machine service, the method includes: Transmitting sequence messages between the AMHS service and the machine service via a message queue, wherein the message queue is an asynchronous communication mechanism to achieve decoupling between services; defining a protocol format that packages a plurality of signal bits into a single sequence message, each sequence message including a digital representation; Maintaining a state sequence, the state sequence comprising a predefined sequence list and a latest sequence state, wherein the index of the sequence list corresponds to the communication step number and the value corresponds to the expected sequence message; When a new sequence message is received, the new sequence message is checked to see if it matches the expected sequence based on the latest sequence state. If so, the latest sequence state is updated to proceed to the next communication step. If not, the new sequence message is rejected and the latest sequence state is reset.

2. The method according to claim 1, wherein The protocol format is a binary format, the bit length is N bits, N is an integer and N≥8, and the number is represented as a hexadecimal or binary string.

3. The method according to claim 1, wherein The signal bits include at least one of the following: VALID, CS_0, CS_1, TR_REQ, L_REQ, U_REQ, READY, BUSY, COMPT, CONT, HO_AVBL, ES, VA, AM_AVBL, VS_0, VS_1, and each signal bit corresponds to a specific position in the protocol format.

4. The method according to claim 1, wherein The message queue includes at least one of the following: MQ message queue, Kafka, RabbitMQ, pub / sub model or cloud-based message service.

5. The method according to claim 1, wherein Maintaining the state sequence includes storing the sequence list as a constant list in a memory and accessing the sequence message through an index.

6. The method according to claim 1, wherein When the new sequence message does not match, the method further includes an error handling step of recording an error log or triggering an alarm.

7. A system for simulating a hardware communication protocol, characterized in that: Applied to a virtual simulation environment, the system includes: AMHS service, configured to generate sequence messages; Machine service, configured to process sequence messages; A message queue component connects the AMHS service and the machine service and is used for asynchronous transmission of sequence messages; a storage module configured to maintain a state sequence, including a predefined sequence list and a latest sequence state, wherein an index of the sequence list corresponds to a communication step number and a value corresponds to an expected sequence message; The verification module is configured to verify whether a new sequence message matches an expected sequence based on the latest sequence state when it is received, and update the latest sequence state if it matches, and reject and reset it if it does not match.

8. The system according to claim 7, wherein: The protocol format is a 16-bit binary format, and each sequence message includes a hexadecimal representation.

9. The system according to claim 7, wherein: The storage module is a memory database or a distributed cache.

10. The system according to claim 7, wherein: The verification module is further configured to perform error handling when the sequences do not match, including generating a log or an alert.

Images