JP2008033794A - Simulator apparatus, simulation method, and control program - Google Patents

Abstract

Provided is a simulator capable of efficiently developing hardware functions of communication equipment and developing control software in the hardware and software collaborative development.
An event that abstracts determination of a bus state, determination of a bus speed, and transmission / reception of data in a USB device controller and a USB host controller composed of actual hardware is generated. This event transmission / reception is provided as a model (USB communication path model 430) that simulates the communication path of the USB device. Further, the delay time in communication is changed according to the type of event. That is, the handling of the delay time is determined with reference to the event ID.
[Selection] Figure 8

Description

  The present invention relates to a simulator device and a simulation method for verifying the operation of a communication device, and a control program for executing the control method.

  A hardware simulator for verifying the operation of hardware including an LSI is conventionally known. For example, Patent Document 1 proposes a technique for performing simulation in consideration of circuit delay when performing functional simulation of a logic circuit.

  Hardware simulators are also used in the development of software that controls hardware, and are also used in hardware and software collaborative development that develops both hardware and software in parallel. .

  On the other hand, the number of devices that use USB has increased, and the number of applications that use proprietary protocols on USB has increased. Along with this, peripheral devices such as a USB host controller and a USB device controller are created in compliance with the USB standard and having unique functions. Here, the USB host controller has a function of performing an operation as a USB host compliant with the USB standard, and the USB device controller has a function of performing an operation as a USB device compliant with the USB standard. I have.

  In such a USB device, it is possible to develop a USB host controller and a USB device controller, develop control software for both controllers, and develop an application protocol using a hardware simulator.

Also, in wireless communication devices, hardware that complies with wireless standards established by IEEE and applications that use the same have become widespread. Similar to USB, a hardware simulator can be used to develop a wireless communication controller that performs wireless communication control and control software for the wireless communication controller.
JP-A-5-174096

  However, the USB host controller and USB device controller use the data communication path used by the software that operates on it to determine the state of the communication path and the bus speed as in the USB standard. ing. In data communication, serialization, signal start synchronization (SYNC signal), decoding and encoding by NRZI (Non-Return to Zero Inverted), and data signal synchronization by bit stuffing are performed.

  Since the operation is complicated as described above, if the communication path of the USB host controller and the USB device controller is directly simulated by the hardware simulator, the calculation processing required for the simulation becomes enormous. As a result, when software development is performed using a USB host controller and a USB device controller, a long execution time is required for calculation processing that is not necessary for software development. Therefore, the execution of software on the simulator is delayed, and the efficiency of software development is reduced.

  Similarly, in the wireless device, if the serial conversion, modulation, and control of the RF (radio frequency) unit, which are controls below the physical layer (PHY), are simulated as they are, the time required for the calculation process becomes enormous. Similar problems arise.

  In this way, the physical layer operation in communication equipment is complex, so in hardware and software co-development, if the operation is simulated on the hardware simulator as it is, the computational load on the simulator will increase significantly. . As a result, there is a problem that the execution of software is delayed at the time of software verification, and the efficiency of software development is lowered.

  In view of the above-described conventional problems, an object of the present invention is to provide a simulator capable of efficiently performing the function development of hardware of communication equipment and the development of its control software in the cooperative development of hardware and software. . It is another object of the present invention to provide a simulation method and a control program for executing the simulation method.

  In order to achieve the above object, the present invention provides a command setting modeling means for simulating the operation of a computing device of a communication device at a command level, and for simulating hardware controlled by the computing device. In a simulator device comprising hardware modeling means, an event generation means for generating an event that abstracts transmission / reception of signals below the physical layer of the communication device is provided, and transmission / reception of the event is performed by a communication path of the communication device. It is provided as a model that simulates

  The present invention also includes command setting modeling means for simulating the operation of the arithmetic device of the wireless communication device at the command level, and hardware modeling means for simulating hardware controlled by the central processing unit. The simulator apparatus includes a frame processing unit that handles a frame generated in the medium access control layer of the communication device as a frame packet below the physical layer, and simulates a wireless communication path of the wireless communication device for transmitting and receiving the frame packet. It features as a model.

  The present invention also includes an instruction setting modeling step for simulating the operation of the arithmetic device of the communication device at an instruction level, and a hardware modeling step for simulating hardware controlled by the arithmetic device. A simulation method for a simulator, comprising: an event generation step for generating an event that abstracts transmission / reception of a signal below a physical layer of the communication device, and transmission / reception of the event to simulate a communication path of the communication device It is characterized by performing.

  The present invention also includes a command setting modeling step for simulating the operation of the arithmetic device of the wireless communication device at a command level, and a hardware modeling step for simulating hardware controlled by the arithmetic device. A simulator simulation method comprising a frame processing step of handling a frame generated in a medium access control layer of the communication device as a frame packet below the physical layer, and for simulating a wireless communication path of the wireless communication device, The transmission / reception of the frame packet is executed.

  According to the present invention, since processing below the physical layer can be simplified, the processing load below the physical layer on the simulator is reduced, and for example, when executing software verification, the execution speed on the simulator is reduced. Software development can be carried out efficiently. That is, it becomes possible to efficiently develop the hardware function of the communication device and the control software on the simulator.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[First Embodiment]
<Hardware simulator platform>
The processing in the present embodiment simulates hardware using software, but even when this simulation is performed, the processing is actually realized by operating hardware such as a computer shown in FIG. Needless to say. Various programs that define the procedure of processing in the present embodiment are stored in the ROM 1207. Various programs are read into the CPU 1206, and the CPU 1206 performs processing such as modeling according to the program, and performs each processing on the model. This also applies to the other embodiments.

  FIG. 1 is a block diagram showing the configuration of a hardware simulator platform according to the first embodiment of the present invention.

  This platform includes a scheduler 101, an ISS (Instruction Set Simulator) 102, a bus model 103, and a peripheral device model 104.

  The scheduler 101 manages time in hardware simulation, and the ISS 102 simulates the operation at the instruction level of the target MPU. The peripheral device device model 104 simulates the operation of peripheral devices (such as a timer controller, a DMA controller, and a memory controller) mounted on the LSI and peripheral circuits (such as RAM, ROM, and external IO) that communicate with the LSI.

  The peripheral device device model 104, the ISS 102, and the peripheral device device model 104 include a bus model 103 that simulates signal processing for data exchange.

  A plurality of ISSs 102, bus models 103, and peripheral device device models 104 can be operated. The target code 110 can also be arranged in the peripheral device device model 104 serving as a storage device for each of the plurality of ISSs 102, and a plurality of systems can be operated on the platform 100 of the hardware simulator.

  Although not shown, the target MPU can place the target code 110 compiled from a program as a group of instructions that can be processed in a storage device that is one of the peripheral device model 104. The ISS 102 sequentially fetches the target code 110 into the ISS 102 and executes processing in the ISS 102 and access to the peripheral device model 104 via the bus model 103 at the timing of the scheduler 101. Then, a simulation similar to the operation of incorporating the target code 110 into actual hardware is performed.

  The hardware simulator platform 100 is software that can be executed on a personal computer, and a C / C ++ language is used to create the peripheral device model 104.

  In this embodiment, the peripheral device model 104 is simulated using the C / C ++ language, but it goes without saying that the same can be done using a language such as HDL or SystemC.

<Hardware simulator for USB communication devices>
Next, the overall configuration of the hardware simulator of the USB communication device will be described.

  FIG. 2 is a block diagram showing the overall configuration of the hardware simulator according to the first embodiment.

  This hardware simulator is a simulator of a system based on the platform 100 shown in FIG. 1, in which a USB device system and a USB host system communicate via a USB communication path.

  The USB device system 210 and the USB host system 220 include a USB device controller model 215, a USB host controller model 225, and MPU (arithmetic unit) models 211 and 221, respectively. Further, RAM models 212 and 222, ROM models 213 and 223, IO models 214 and 224, and bus models 216 and 226 are also provided.

  The MPU models 211 and 221 correspond to the ISS 102 and read target codes. The RAM models 212 and 222 are one of the peripheral device model 104, and are used as work areas in the respective systems. The ROM models 213 and 223 are one of the peripheral device model 104, and store and hold a target code 110 which is a program for operating the USB device system 210 and the USB host system 220 (not shown). deep.

  The IO model 214 is one of the peripheral device device models 104 and is an IO (input / output unit) for communicating with the outside of the USB device system 210 and the USB host system 220. The USB device controller model 215 is one of the peripheral device model 104, and includes a USB_I / F that operates as a USB device that conforms to a known USB standard. The USB host controller model 225 is one of the peripheral device model 104, and includes a USB_I / F (interface) that operates as a USB host compliant with a known USB standard.

  The bus model 216 is one of the bus models 103 and is used to exchange data between the MPU model 211, the RAM model 212, the ROM model 213, the IO model 214, and the USB device / controller model 215. . The bus model 225 is one of the bus models 103 and is used to exchange data between the MPU model 221, the RAM model 222, the ROM model 223, the IO model 224, and the USB host controller model 225. .

  The USB communication path model 230 connects the USB_I / F of the USB device / controller model 215 and the USB_I / F of the USB host / controller model 225 to simulate USB communication.

<Actual configuration of USB device controller>
Next, the actual hardware configuration and operation of the USB device controller model 215 will be described.

(A) Configuration FIG. 3 is an actual hardware configuration diagram of the USB device controller model 215.

  The USB device controller 310 is actual hardware of the USB device controller model 215 and includes a system bus I / F 311, a USB engine 312, a USB transceiver 313, a FIFO 314, and a VBus management unit 315.

  The system bus I / F 311 is an interface for the USB device controller model 215 to access. The USB engine 312 analyzes a USB protocol compliant with a known USB standard, and performs a function process of the USB device controller. The USB transceiver 313 is a USB transceiver that receives and transmits a signal in USB communication conforming to a known USB standard. “D +” 316 and “D−” 317 in FIG. 3 are data signal lines for transmitting signals in the USB transceiver 313.

  The FIFO 314 temporarily holds USB packet data in USB data transmission / reception. The VBus management unit 315 detects the amount of voltage and current supplied from a USB host that conforms to a known USB standard. In FIG. 3, reference numeral 318 denotes a power transmission path VBus supplied from the USB host, and reference numeral 319 denotes a ground serving as a reference for the VBus 318 from the USB host.

  When power is supplied from the USB host to the VBus 318 and the VBus management unit 315 determines that the voltage is a constant voltage conforming to a known USB standard, the USB engine 312 is notified. Further, the USB transceiver 313 is used to perform initialization processing with the USB host to transmit / receive USB packet data.

  The data received by the USB transceiver 313 is analyzed by the USB engine 312, the data is held in the FIFO 314, the MPU (not shown) is notified via the system bus I / F 311, and the next appropriate processing is awaited. In addition, USB packet data to be transmitted from the MPU to the FIFO 314 via the system bus I / F 311 is written. When the USB engine 312 receives a transmission instruction, the USB engine 312 sends the USB packet data in the FIFO 314 to the USB transceiver 313.

  The USB transceiver 313 performs signal transmission processing and USB packet data encoding in accordance with a known USB standard, and performs signal changes of “D +” 316 and “D−” 317 in accordance with predetermined time processing. So-called serial communication is performed by the USB transceiver 313.

  Further, the USB engine 312 performs a reset process, a suspend process, and a resume process depending on the power state of the VBus 318 and the signal states of “D +” 316 and “D−” 317. Further, the communication speed for communication between the USB host controller and the USB device controller is also determined. These will be described below. The well-known USB standard defines a bus state in a combination of the signal state of “D +” 316 and “D−” 317 and the bus speed of the USB bus in a bus (hereinafter referred to as USB bus) with which USB communicates ( Refer to the USB specification.)

(B) Reset When the signal states of “D +” 316 and “D−” 317 are both Low and continue for at least 10 mm or more, the USB engine 312 performs reset processing and recognizes that the bus is in the reset state. To do.

  The bus speed is set so that the USB device controller 310 sets the potential of the “D +” 316 to be higher than the “D−” 317 before the USB bus state is “Reset”, thereby indicating that the bus speed is a Full Speed device. Tell the host controller. By making the potential of “D−” 317 higher than “D +” 316, the USB host controller is informed that the device has a bus speed of Low Speed. After the USB host controller determines whether the bus speed should be Low Speed or Full Speed, the USB host controller resets the bus state.

  In the reset state, when the USB device controller 310 is a high-speed device, a signal pulse (hereinafter referred to as ChirpK) in which the potential of “D−” 317 is increased and at the same time the potential of “D−” 316 is set to 0 is output. . On the other hand, if the USB host controller can communicate with High Speed, the potential of “D +” 316 is increased, and the potential of “D−” 317 is set to 0 at the same time. Next, the potential of “D +” 316 is set to 0, and at the same time, the signal state of “D−” 317 is increased (hereinafter referred to as KJ state).

  This is repeated, and the USB host controller informs the USB device controller 310 that it can communicate at the high speed bus speed. Then, the USB host controller and the USB device controller 310 escape from the reset state, and thereafter perform communication with High Speed. When the USB host controller does not repeat the KJ state with respect to ChirpK, mutual communication is performed with Full Speed.

(C) Start of data transfer and encoding The USB packet data is transmitted with a SYNC signal when the USB bus state is idle. The SYNC signal is a repetition of the KJ state. When the high / low speed bus speed is transmitted continuously for 8 bits, and when the high speed is transmitted, 15 times are transmitted continuously, and then the KK state is transmitted.

  Following this, data is transitioned. The data is encoded by NRZI (Non-Return to Zero Inverted) with bit stuffing and transmitted. Finally, an EnD-of-Packet signal is transmitted, indicating that the USB data packet has been transmitted.

  In this way, the USB device controller 310 changes the signals “D +” 316 and “D−” 317 to determine the bus state, the bus speed, and send / receive data with the USB host controller. .

  The USB host controller has not been described. However, in order to suppress the main points of the present invention, the signal change of “D +” 316 and “D−” 317 of the USB device controller 310 can be described. Further, the VBus 318 in the USB host controller can be regarded as the behavior on the supply side, and thus the description is omitted.

<Modeling of USB communication>
Next, detailed modeling of the USB device controller model 215, the USB host controller model 225, and the USB communication path model 230 will be described.

(A) Each model of USB communication FIG. 4 is a block diagram illustrating a main part of a controller and a communication path model related to USB communication in the hardware simulator of the present embodiment.

  In the hardware simulator of this embodiment, a USB device system unit 410 and a USB host system unit 420 are connected via a USB communication path model 430.

  The USB device system unit 410 is a part obtained by modeling the USB engine 312 and the USB transceiver 313 included in the USB device controller 310 in the USB device controller model 215. A USB device engine model 411 and an I / F 412 are provided.

  The USB device engine model 411 interprets a packet that is a function of the USB engine 312 of the USB device controller 310 and detects whether or not a VBus that is a function performed by the VBus management unit 315 is supplied. The I / F 412 is an interface for causing the USB device engine model 410 to notify the USB communication path model 430 of determination of the bus state, determination of the bus speed, and transmission / reception of data as events.

  The USB host system unit 420 is a part that models the USB engine and USB transceiver of the USB host controller in the USB host controller model 225. A USB host engine model 423 and an I / F 422 are provided. The USB host engine model 423 is a model having a function of interpreting a packet, which is a function of the USB engine of the USB host controller, and a function of supplying VBus. The I / F 422 is an interface for causing the USB host engine model 420 to notify the USB communication path model 430 of determination of the bus state, determination of the bus speed, and transmission / reception of data as events.

  The USB communication path model 430 is a USB communication path model that connects the USB device engine model 410 and the USB host engine model 420, and performs determination of the bus state, determination of the bus speed, and transmission / reception of data. This corresponds to the USB communication path model 230 of the actual USB device controller and host controller.

(B) Content of event The above event is an abstraction of the determination of the bus state, the determination of the bus speed, and the transmission / reception of data in the USB device controller and the USB host controller which are actual hardware. The contents of this event will be described below.

  FIG. 5 is a diagram illustrating a structure of an event (USB Event Packet), and FIG. 6 is a diagram illustrating an event ID (USB Event ID) and the contents of the event.

  Reference numeral 501 in FIG. 5 denotes a USB Event Packet ID. This is an ID issued to identify each USB Event Packet when it is generated by a USB device controller and a USB host controller, which are actual hardware, and passed to the USB communication path model 430. is there.

  Reference numeral 502 in FIG. 5 denotes an Event ID that is the same value as the Event ID shown in FIG. Reference numeral 503 denotes a simulation time when the USB device engine model 410 or the USB host engine model 420 delivers the USB Event Packet to the USB communication path model 430. This time is a simulation time that can be acquired from the scheduler 101.

  Reference numeral 504 denotes simulation time when the USB device engine model 410 or the USB host engine model 420 receives the USB Event Packet from the USB communication path model 430. Reference numeral 505 denotes the size of the USB packet data 506. This relates to the case of Transfer USB Packet Data in FIG. 6 in which the USB Event Packet ID 501 is a value of 6.

  Reference numeral 506 denotes USB Packet Data that is transmitted and received when the USB Event Packet ID 501 is the Transfer USB Packet Data of FIG.

(C) I / F for event notification
Next, regarding the processing in the I / F 412 when an event issue request is received from the USB device engine model 411 to the I / F 412 when requesting that the USB device controller model 215 is Full Speed This will be described with reference to FIG.

  FIG. 7 is a flowchart showing a process for issuing a Request Full Speed event.

  When an event issue request is received, the I / F 412 first acquires a simulation time from the scheduler 101 (S701). Then, an instance of the USB Event Packet 500 is generated, and Event ID = 3 which is a request Full Speed is input to the Event ID 502 as can be seen from FIG.

  Then, the simulation time acquired in S701 is input to the Event issued time 503 (S702), and the instance of the USB Event Packet 500 created in S702 is passed to the USB communication path model 430 (S703).

  In the example of FIG. 7, the event issuance process from the USB device engine model 411 to the I / F 412 is performed, but the event issuance process from the USB host engine model 423 to the I / F 422 is performed in the same manner.

  The same process is performed when the Event ID is another ID. When the Event ID is USB Transfer Packet Data, an instance of USB Packet Data transmitted from the USB device engine model 411 to the I / F 412 is received. Then, the input to the USB Packet Data 506 of the USB Event Packet 500 and the size thereof are calculated, and the calculation result only needs to be input to the USB Packet Data Size 505.

(D) Processing of USB Communication Path Model The USB communication path model 430 receives an instance of the USB Event Packet 500 from the USB device engine model 411 via the I / F 412. The processing of the USB communication path model 430 when transferring this instance to the USB host engine model 423 via the I / F 224 will be described with reference to FIG.

  FIG. 8 is a flowchart showing processing of the USB communication path model.

  An ID different from the other USB Event Packet 500 instances is assigned to the received USB Event Packet 500 instance (S801). Subsequently, the Event ID 502 is acquired from the instance (S802), and it is determined whether or not the Event ID is Transfer USB Packet Data (S803).

  If it is not Transfer USB Packet Data, sufficient time should not be required even with actual hardware, so a predetermined time is set as a time required for event notification (S804). In the case of Transfer USB Packet Data, the bit length actually transmitted from the USB packet is calculated after including bit stuffing, and is set as the time required for transfer from the bus speed (S805).

  After that, the time obtained by adding the Event issued time 503 of the instance of the USB Event Packet 500 to the time required for event transmission calculated in S804 and S805 is input to the Event received time (S806). Further, it is determined whether the Event ID 502 acquired in S802 is an ID for determining the bus speed (S807). If the ID is for determining the bus speed, the bus speed is stored in the USB communication path model (S808). ).

  In next step S809, the simulation time is acquired from the scheduler 809, and it is determined whether the acquired value is equal to or greater than the event received time 504 of the instance of the USB Event Packet 500 set in step S808 (S810). If it is not equal to or greater than Event received time 504, the process returns to S809 again to acquire the simulation time, and the determination of S810 is performed. If the event received time 504 set in S808 or more, an instance of the USB Event Packet 500 is transmitted to the I / F 224 (S811).

  When the I / F 224 receives an instance of the USB Event Packet 500 from the USB communication path model 430, it notifies the USB host engine model of what event has been received.

  The USB communication path model 430 receives an instance of the USB Event Packet 500 from the model 211 via the I / F 214 and passes it to the model 221 via the I / F 224. The processing of the USB communication path model 430 has been described. Needless to say, the reverse can be easily performed.

  Further, the notification from the I / Fs 412 and 422 to the USB device engine model 411 and the USB host controller model 423 is performed by API for each event.

  As described above, in this embodiment, transmission / reception of signals below the physical layer is performed by exchanging abstract data called events. With this configuration, the simulation of the USB device including the USB device controller model 215 and the USB host controller model 225 can reduce the processing load compared to the simulation of the model that simulates the USB signal processing.

  In the present embodiment, only the events as shown in FIG. 6 have been described, but it goes without saying that other USB events can be easily implemented.

<Advantages of the first embodiment>
In the hardware simulator according to the first embodiment, the bus state determination, bus speed determination, and data transmission / reception in the USB device controller and the USB host controller made of actual hardware are abstracted. An event is generated (FIG. 5). This event transmission / reception is provided as a model (USB communication path model 430) that simulates the communication path of the USB device (FIG. 8). As a result, the processing by the USB device controller and the USB host controller can be simplified, thereby reducing the processing load on the simulator.

  Accordingly, when software development is performed using the USB host controller model 225 and the USB device controller model 215, it is possible to reduce the execution time of calculation processing that is not necessary for software development. That is, software development can be efficiently performed without reducing the execution speed on the simulator.

Further, the delay time in communication is changed according to the type of event (FIG. 6). That is, the handling of the delay time is determined with reference to the event ID (steps S803 to S806 in FIG. 8). As a result, the communication time can be simulated with high accuracy.
[Second Embodiment]
In the second embodiment, a hardware simulator in a wireless communication system including a controller with a wireless communication function will be described. The hardware simulator platform is the same as that shown in FIG. In the present embodiment, for example, a system simulator in which three wireless communication systems perform wireless communication will be described.

  Although not shown, the simulator of the wireless communication system of the present embodiment includes an MPU model that simulates an instruction level, a ROM model that stores a program that controls the wireless communication system, and a RAM model that is used as a primary work area. Prepare. In addition, a wireless communication controller model for performing wireless communication control for communicating with an external wireless device, and a system bus model for these models to access each other are provided.

<Configuration of wireless communication controller>
Next, an actual hardware configuration of a wireless communication controller that performs wireless communication control will be described.

  FIG. 9 is a block diagram showing an actual hardware configuration of the wireless communication controller according to the second embodiment of the present invention.

  The wireless communication controller 900 includes a system bus I / F 901, a control unit 902, a MAC unit 903, a PHY unit 904, and an RF unit 905.

  The system bus I / F 901 is an interface for accessing each other peripheral device on the system via the system bus. The control unit 902 has a function as a control interface for software in wireless communication of the wireless communication controller.

  The MAC unit 903 creates and analyzes a frame structure compliant with a wireless standard, performs wireless channel access control using a collision avoidance function, and performs management between the base station and the terminal station. The PHY unit 904 modulates and demodulates the frame data, and the RF unit 905 performs radio transmission and reception.

  At the time of data transmission, the control unit 902 temporarily receives the transmission data via the system bus I / F 901 and passes the transmission data to the MAC unit 903. The MAC unit 903 creates one or more wireless standard frame structures based on the transmission data, and passes the frames to the PHY unit 904. The PHY unit 904 modulates the frame. The frame is transmitted from the RF unit 905 with a predetermined frequency band.

  At the time of data reception, the RF unit 905 receives data, and the PHY unit 904 demodulates the received data to create a frame. Then, the MAC unit 903 analyzes the frame and passes the data to the controller unit 902. A program for controlling the wireless communication controller receives and processes the data.

<Modeling of wireless communication controller>
Next, modeling for simulating the wireless communication controller 900 will be described with reference to FIG.

  FIG. 10 is a block diagram illustrating a main part of a wireless communication controller and a communication path model in the hardware simulator according to the second embodiment.

  In the hardware simulator according to the present embodiment, as shown in FIG. 10, three wireless communication controller models 1010, 1020, 1030 are connected via a wireless communication path model 1040.

  Radio communication controller models 1010, 1020, and 1030 shown in FIG. 10 are models of radio communication controller units that clearly indicate the following MAC units of the model of the radio communication controller 900 that is actual hardware. In FIG. 10, portions corresponding to the system bus I / F 901 and the control unit 902 are not shown, but the functions of the system bus I / F 901 and the control unit 902 are simulated as a model of the wireless communication controller 900. Is.

  The wireless communication controller models 1010, 1020, and 1030 include MAC unit models 1011, 1021, and 1031 and PHY_I / F units 1012, 1022, and 1032, respectively.

  The MAC unit models 1011, 1021, and 1031 are models having functions corresponding to the MAC unit 903. The PHY_I / F units 1012, 1022, and 1032 receive the frame data created by the MAC units 1011, 1021, and 1031 and create a frame packet. Further, it has a function of analyzing the frame packet when it is received and sending the frame data to the MAC units 1011, 1021, and 1031.

  The wireless communication path model 1040 transmits to the PHY_I / F unit other than the PHY_I / F unit that transmitted the frame packet transmitted by the PHY_I / F units 1012, 1022, and 1032 after being delayed by the time that the actual RF unit transmits. It has a function.

<Frame packet structure>
Next, the structure of the frame packet created and analyzed by the PHY unit I / F units 1012, 1022, and 1032 will be described with reference to FIG.

  FIG. 11 is a diagram illustrating a structure of a frame packet according to the second embodiment.

  The frame packet according to the second embodiment includes data such as “Frame ID” 1101, “Shift Keying Type” 1102, “Frequency Spectrum” 1103, and “Frame State” 1104. Furthermore, the data includes “Frame Issued Time” 1105, “Frame Issued Time” 1106, “Data Size” 1107, and “Frame Data” 1108.

  “Frame ID” 1101 is an ID for identifying a frame packet issued by the wireless communication path model 1040. “Shift Keying Type” 1102 is data indicating a modulation scheme of the PHY_I / F units 1012, 1022, and 1032. “Frequency Spectrum” 1103 is data indicating a frequency band to be transmitted by RF modulated by the PHY_I / F units 1012, 1022, and 1032.

  “Frame State” 1104 is data indicating a state of whether the frame packet is abnormal or normal, and “Frame State” 1104 indicates a state in which radio wave interference is actually caused and the frame cannot be demodulated. Use when.

  “Frame Issued Time” 1105 is data indicating simulation time when a frame is transmitted from the PHY_I / F units 1012, 1022, and 1032 to the wireless communication path model 1040. “Frame Issued Time” 1106 is data indicating a simulation time when a frame packet is transmitted from the wireless path model 1040 to the PHY_I / F units 1012, 1022, and 1032.

  “Data Size” 1107 is data indicating the size of the frame data generated by the MAC units 1011, 1021, and 1031, and “Frame Data” 1108 is frame data generated by the MAC units 1011, 1021, and 1031.

<Advantages of Second Embodiment>
In the hardware simulator according to the second embodiment, a frame generated by the MAC unit of the wireless communication controller 900 made of actual hardware is handled as a frame packet (FIG. 11). This frame packet transmission / reception is provided as a model (wireless communication path model 1040) for simulating the wireless communication path of the wireless communication device.

  Thereby, the processing of the PHY unit 904 and the RF unit 905 of the wireless communication controller can be simplified, and the execution speed on the simulator can be increased. In addition, the upper level of the PHY unit 904, that is, the system bus I / F 901, the control unit 902, and the MAC unit 903 is a simulator having a model equivalent to the actual hardware. Therefore, in the hardware and software collaborative development, it is possible to efficiently develop the hardware function of the wireless communication device and the control software.

  In this embodiment, the wireless function conforms to IEEE802.11b which is a known standard, but it is not difficult to apply other wireless standards. In this embodiment, the description has been made with three systems. However, the number of the systems does not have the point of the present invention, and the present invention can be applied to other plural systems.

  An object of the present invention is to supply a storage medium storing software program codes for realizing the functions of the above-described embodiments to a system or apparatus, and the computer of the system or apparatus reads and executes the program codes. Can also be achieved.

  In this case, the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the program code and the storage medium storing the program code constitute the present invention. .

  Examples of the storage medium for supplying the program code include the following. That is, a floppy (registered trademark) disk, hard disk, magneto-optical disk, CDROM, CDR, CDRW, DVDROM, DVDRAM, DVDRW, DV “D +” RW or other optical disk, magnetic tape, nonvolatile memory card, ROM, or the like is used. Can do. Alternatively, the program code may be downloaded via a network.

  The present invention not only realizes the functions of the above-described embodiments by executing the program code read by the computer. In some cases, an OS (operating system) or the like running on the computer performs part or all of the actual processing based on the instruction of the program code, and the functions of the above-described embodiments are realized by the processing. included.

It is a block diagram which shows the structure of the platform of the hardware simulator which concerns on 1st Embodiment. It is a block diagram which shows the whole structure of the hardware simulator which concerns on 1st Embodiment. It is a block diagram of the actual hardware of a USB device controller model. FIG. 3 is a block diagram illustrating a main part of a controller and a communication path model related to USB communication in the hardware simulator of the embodiment. It is a figure which shows the structure of an event. It is a figure which shows event ID and the content of an event. It is a flowchart which shows issue processing of a Request Full Speed event. It is a flowchart which shows the process of a USB communication path | route model. It is a block diagram which shows the actual hardware constitutions of the radio | wireless communication controller which concerns on 2nd Embodiment. In the hardware simulator which concerns on 2nd Embodiment, it is a block diagram which shows the principal part of the model of a radio | wireless communication controller and a communication path. It is a figure which shows the structure of the frame packet which concerns on 2nd Embodiment. It is a block diagram which shows the general | schematic function of the computer which implement | achieves the hardware simulator which concerns on 1st and 2nd embodiment.

Explanation of symbols

230 USB communication path model 410 USB device system unit 420 USB host system unit 1010, 1020, 1030 Wireless communication controller model 1040 Wireless communication path model

Claims (10)

In a simulator device comprising instruction setting modeling means for simulating the operation of an arithmetic device of a communication device at an instruction level, and hardware modeling means for simulating hardware controlled by the arithmetic device,
Providing an event generation means for generating an event that abstracts the transmission and reception of signals below the physical layer of the communication device;
A simulator apparatus comprising transmission / reception of the event as a model for simulating a communication path of the communication device.   The simulator apparatus according to claim 1, further comprising means for simulating a delay in communication according to the contents of the event.   The simulator apparatus according to claim 2, wherein handling of a delay in the communication is determined with reference to an event ID that uniquely determines the content of the event.   The simulator device according to claim 1, wherein the communication device is a communication device using a USB.   5. The simulator apparatus according to claim 4, wherein the contents of the event include bus reset, bus speed request, bus speed determination, and USB packet transfer in USB specifications. In a simulator device comprising: instruction setting modeling means for simulating the operation of a computing device of a wireless communication device at an instruction level; and hardware modeling means for simulating hardware controlled by the central computing device,
Frame processing means for handling a frame generated in the medium access control layer of the communication device as a frame packet below the physical layer,
A simulator device comprising transmission / reception of the frame packet as a model for simulating a wireless communication path of the wireless communication device. A simulator simulation method comprising: an instruction setting modeling step for simulating the operation of an arithmetic device of a communication device at an instruction level; and a hardware modeling step for simulating hardware controlled by the arithmetic device. There,
An event generation step of generating an event that abstracts transmission and reception of signals below the physical layer of the communication device;
A simulation method, wherein transmission / reception of the event is executed in order to simulate a communication path of the communication device. A simulator simulation method comprising a command setting modeling step for simulating the operation of a computing device of a wireless communication device at a command level, and a hardware modeling step for simulating hardware controlled by the computing device. And
A frame processing step of handling a frame generated in the medium access control layer of the communication device as a frame packet below the physical layer;
A simulation method, comprising: transmitting and receiving the frame packet in order to simulate a wireless communication path of the wireless communication device.   A control program for executing the simulation method according to claim 7.   A control program for executing the simulation method according to claim 8.

Images