Nothing Special   »   [go: up one dir, main page]

USRE42227E1 - Apparatus and method for connecting hardware to a circuit simulation - Google Patents

Apparatus and method for connecting hardware to a circuit simulation Download PDF

Info

Publication number
USRE42227E1
USRE42227E1 US12/481,943 US48194309A USRE42227E US RE42227 E1 USRE42227 E1 US RE42227E1 US 48194309 A US48194309 A US 48194309A US RE42227 E USRE42227 E US RE42227E
Authority
US
United States
Prior art keywords
data
simulation
peripheral device
hardware peripheral
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime, expires
Application number
US12/481,943
Inventor
Robert Marc Zeidman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Unwired Broadband Inc
Original Assignee
Ionipas Transfer Co LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/751,573 external-priority patent/US7050962B2/en
Priority claimed from US10/158,648 external-priority patent/US7266490B2/en
Priority to US12/481,943 priority Critical patent/USRE42227E1/en
Application filed by Ionipas Transfer Co LLC filed Critical Ionipas Transfer Co LLC
Assigned to IONIPAS TRANSFER COMPANY, LLC reassignment IONIPAS TRANSFER COMPANY, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ZEIDMAN, ROBERT M.
Assigned to ZEIDMAN, ROBERT reassignment ZEIDMAN, ROBERT ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ZEIDMAN TECHNOLOGIES, INC.
Assigned to ZEIDMAN TECHNOLOGIES reassignment ZEIDMAN TECHNOLOGIES ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ZEIDMAN, ROBERT M.
Publication of USRE42227E1 publication Critical patent/USRE42227E1/en
Application granted granted Critical
Assigned to OL SECURITY LIMITED LIABILITY COMPANY reassignment OL SECURITY LIMITED LIABILITY COMPANY MERGER (SEE DOCUMENT FOR DETAILS). Assignors: IONIPAS TRANSFER COMPANY, LLC
Assigned to INTELLECTUAL VENTURES ASSETS 130 LLC reassignment INTELLECTUAL VENTURES ASSETS 130 LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: OL SECURITY LIMITED LIABILITY COMPANY
Assigned to COMMWORKS SOLUTIONS, LLC reassignment COMMWORKS SOLUTIONS, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INTELLECTUAL VENTURES ASSETS 130 LLC
Assigned to UNWIRED SOLUTIONS, INC. reassignment UNWIRED SOLUTIONS, INC. LICENSE (SEE DOCUMENT FOR DETAILS). Assignors: COMMWORKS SOLUTIONS, LLC
Assigned to UNWIRED BROADBAND, INC. reassignment UNWIRED BROADBAND, INC. CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE NAME PREVIOUSLY RECORDED AT REEL: 054443 FRAME: 0958. ASSIGNOR(S) HEREBY CONFIRMS THE LICENSE. Assignors: COMMWORKS SOLUTIONS, LLC
Assigned to UNWIRED BROADBAND, INC. reassignment UNWIRED BROADBAND, INC. CORRECTIVE ASSIGNMENT TO CORRECT THE THE NATURE OF CONVEYANCE PREVIOUSLY RECORDED AT REEL: 056981 FRAME: 0631. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: COMMWORKS SOLUTIONS, LLC
Adjusted expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking

Definitions

  • the integrated circuit design Prior to reducing an integrated circuit design to a form suitable for fabrication, the integrated circuit design is often simulated in software on a computer to allow the design to be optimized and debugged. Typically, using a hardware description language (e.g., Verilog), the circuit designer prepares a description of the integrated circuit, which is then compiled into a software model to be simulated on the computer (e.g., an engineering workstation).
  • a hardware description language e.g., Verilog
  • peripheral hardware such as an LCD display or a Universal Serial Bus (USB) port
  • peripheral hardware is modeled in the hardware description language and communication with the peripheral hardware is also simulated.
  • a model of the peripheral hardware does not behave completely accurately and correctly.
  • the present invention allows a logic circuit simulator running on a host computer (e.g., a personal computer) and simulating a circuit (“simulated device”) to connect to a physical peripheral hardware device.
  • the present invention provides a method and an apparatus for transferring data between a circuit simulation and the peripheral hardware device.
  • an interface software program also installed on said host computer is provided to handle communication between the operating system drivers for the peripheral hardware device and the simulated device.
  • the peripheral hardware device can be, for example, a computer display monitor.
  • data sent to a simulated device from a physical peripheral hardware device is received by the interface software and stored in buffers in the existing memory in the host computer.
  • Said interface software in said host computer repackages the data into a second format for transmission to said simulated device.
  • the data from said physical peripheral hardware device is sent to the operating system of said host computer.
  • Said interface software intercepts said data and examines it. If said data is intended for said simulated device, said interface software loads it into said data buffers, subsequently repackages said data into a second format for transmission to said simulated device and sends said repackaged data to the simulated device. If said data from said physical peripheral hardware device is not intended for said simulated device, said interface software program sends said data on to said host computer operating system.
  • the interface software in the host computer repackages data received from the simulated device into proper format for transmission to the physical peripheral hardware device.
  • the existing memory in the host computer is used to buffer data communicated between said simulated device and said physical peripheral hardware device.
  • the data from said simulated device is sent to the interface software program. If said data is intended for said physical peripheral hardware device, said interface software program repackages said data and sends said data to said host computer operating system for transmission to said physical peripheral hardware device. Said operating system is notified that said data is intended for said physical peripheral hardware device because said interface software program uses a specific application program interface (API) of the operating system used specifically to access said physical peripheral hardware device.
  • API application program interface
  • the interface software of the host computer is implemented as a multithread program including four executing threads.
  • One thread is a task that receives data from the physical peripheral hardware device and stores said received data in a first buffer.
  • a second thread is a task that polls said first buffer for said received data. This second thread repackages said received data and sends said repackaged data via the simulation interface to the simulated device.
  • a third thread is a task that receives data from said simulated device via said simulation interface and stores said received data in a second buffer.
  • a fourth thread is a task that polls said second buffer for said data received from said simulated device. Said fourth thread repackages said data received from said simulated device and sends said repackaged data to said physical peripheral hardware device using an API of the operating system software of said host computer.
  • the interface software of the host computer is implemented as a multithread program, as in the previous embodiment, except that the second buffer is eliminated and the third and fourth threads are combined into a single thread.
  • the tasks of the single thread receive data from the simulated device via the simulation interface, repackages said received data and sends said repackaged to said physical peripheral hardware device using an API of the operating system software of said host computer. This approach is possible because a circuit simulation runs at a much slower speed than the physical peripheral hardware device, such that data received from the simulated device can be repackaged and sent to the physical peripheral hardware device before the next data packet's arrival from the circuit simulation.
  • the interface software of the host computer is implemented as a multithreaded program having, in one instance, two executing threads.
  • One thread is a task that receives data from the physical peripheral hardware device, stores said received data in a buffer, retrieves said stored data for repackaging, and sends said repackaged data via a simulation interface to the simulated device.
  • Another thread is a task that receives data from said simulated device via said simulation interface from said simulated device, repackages said data and sends said repackaged data to said physical peripheral hardware device using an API of the operating system software of said host computer.
  • FIG. 1 shows a computer with various hardware peripherals including built-in peripherals and external peripherals.
  • FIG. 2 shows a block diagram of typical computer software including low-level hardware drivers, an operating system, application programs, and a user interface.
  • FIG. 3 is a block diagram showing the functions performed by SoftBridge program 200 , in accordance with one embodiment of the present invention.
  • FIG. 4 is a block diagram showing the functions performed by SoftBridge program 200 , in accordance with a second embodiment of the present invention.
  • FIG. 5 is a block diagram showing the functions performed by SoftBridge program 200 , in accordance with a third embodiment of the present invention.
  • FIG. 1 shows a typical computer configuration that implements the present invention.
  • the processor 101 connects via high-speed processor-system bus 120 to the cache controller 102 and the cache memory 103 .
  • Said cache controller 102 connects via a medium speed memory-system bus 130 to main memory 104 and bridge 105 as well as to high speed peripheral devices such as fast mass storage device 106 , fast display 107 , and other fast peripherals 108 .
  • said processor 101 also connects directly via medium speed memory-system bus 130 to said high speed peripherals fast mass storage device 106 , fast display 107 , and other fast peripherals 108 .
  • Said bridge 105 acts to connect the medium speed memory-system bus 130 to low-speed system bus 140 which connects to slow peripherals slow display 109 , keyboard 110 , mouse 111 , slow mass storage device 112 , printer 113 , and slow peripherals 114 . All peripherals, fast or slow, are shown in shaded box 150 . Note that peripherals may in fact be boards or chips that drive peripheral devices, but for the purposes of this invention, we do not differentiate between the chips or board that drives a peripheral and the peripheral itself.
  • FIG. 2 shows a block diagram of the software executing on processor 101 .
  • the driver software for hardware peripherals 205 This software, usually supplied by the manufacturer of said peripherals allows computer operating system software 204 to access said peripherals without detailed knowledge of the hardware design or the operation of said peripherals.
  • Said operating system also includes routines called hardware peripheral application program interfaces (APIs) 202 that allow application programs to indirectly access the hardware peripherals via said operating system.
  • APIs hardware peripheral application program interfaces
  • a circuit simulation program 203 runs at a higher level than the operating system and uses the operating system to communicate with the user to display information via a peripheral such as a monitor or a printer. Said simulation program also uses the operating system to get information from a user via the mouse or keyboard.
  • the operating system 204 also allows said simulation 203 and other applications to be running simultaneously and allocates time and resources to all applications according to set priorities.
  • SoftBridge program 200 an application program that runs on top of the operating system, which controls the computer resources allocated to it.
  • the SoftBridge program 200 can communicate to the simulation 203 via a software interface called a programming language interface (PLI) 206 .
  • PLI programming language interface
  • the SoftBridge program 200 can use the hardware peripheral APIs 202 to access the hardware peripherals indirectly. In some cases, to increase performance for example, it may be necessary for the SoftBridge program 200 to access the driver software 205 directly, bypassing the operating system 204 and the APIs provided by the operating system.
  • the user interface 201 is the part of the SoftBridge program 200 that allows the human user to enter information and control operation of the program 200 . Said user interface 201 also gives results back to the human user.
  • a circuit simulation of a device that drives a hardware peripheral would output raw data. An engineer would then look over the data and compare it manually to a specification for said hardware peripheral to determine whether the data is correct. This manual checking of data is a time consuming operation that is prone to human error and limits the amount of simulation that can be run because time in the development process must be allocated for humans to check the results.
  • Another prior art method is to create a circuit simulation of the hardware peripheral (“simulated peripheral”) and have the simulated device drive the simulated peripheral and observe that the correct behavior occurs. This method requires that an engineer write a model for said hardware peripheral. Not only does this take time to develop said model, but the model itself is prone to human error because it may not be completely correct and may thus not accurately model the true behavior of the peripheral hardware. Because the circuit simulation software must now simulate not only the device that drives the software but also the peripheral hardware device being driven, the simulation software runs much slower.
  • a simulated device that receives data from a hardware peripheral would need to have raw data written by an engineer and then used by the simulation software as stimuli for the device.
  • This manual creation of data is a time consuming operation that is prone to human error and limits the amount of simulation that can be run because time in the development process must be allocated for humans to create the data.
  • Another prior art method is to create a circuit simulation of the hardware peripheral and have the simulated peripheral drive the simulated device and observe that the behavior is correct. This method requires that an engineer write a model for the hardware peripheral. Not only does this take time to develop said model, but the model itself is prone to human error because it may not be completely correct and may thus not accurately model the true behavior of the peripheral hardware. Because the circuit simulation software must now simulate not only the device that drives the software but also the peripheral hardware device being driven, the simulation software runs much slower.
  • a hardware peripheral device is connected, pin by pin, to another hardware peripheral device called a hardware modeler interface, which is in turn connected to a host computer.
  • Said host computer runs a circuit simulation of a device.
  • said simulation software notifies special hardware modeling software, which forces said hardware modeler interface to assert or deassert signals to said hardware peripheral according to the simulated device outputs.
  • said signals are sent to said hardware modeler interface, which notifies said hardware modeling software, which in turn notifies said simulation software, which stimulates said simulated device.
  • This method requires very specialized software, the hardware modeling software, to interface between the simulation software and the hardware modeler interface.
  • the hardware modeler interface is a costly, specialized piece of hardware that must physically be connected to the hardware peripheral. Said hardware modeler interface is limited to connecting to certain hardware peripheral devices by the type and size of the connectors that it has available. For example, to connect to an ISA card, said hardware modeler interface must have an ISA connector and to connect to a PCI card, said hardware modeler interface must have a PCI connector. To be able to connect to any kind of peripheral device would require said hardware modeler interface to comprise an extremely large circuit board with dozens of connectors, or consist of dozens of different boards for connecting to different peripheral hardware devices.
  • the present invention overcomes the limitations of the prior art by interfacing a real hardware peripheral to the circuit simulation of said device, taking advantage of standard software that is easily available and has already been fully tested.
  • This standard software includes driver software and APIs that are written by the hardware peripheral manufacturer and are included in most standard operating systems.
  • data from the circuit simulation 203 of said device that is intended to drive said hardware peripheral is sent to the SoftBridge program 200 from the circuit simulation program PLI.
  • the SoftBridge program 200 sends said data to the hardware peripheral either via the hardware peripheral API 202 of the operating system or directly to the hardware peripheral device drivers 205 .
  • Data from the hardware peripherals is retrieved by the SoftBridge program 200 either from the hardware peripheral API 202 of the operating system or directly from the hardware peripheral device drivers 205 .
  • the SoftBridge program 200 sends said data to the circuit simulation 203 via the circuit simulation program PLI.
  • FIG. 3 shows a block diagram of the SoftBridge program.
  • the SoftBridge program 200 has a start routine 301 that initiates the program and begins execution upon input from the user.
  • Said start routine initializes four independent threads that run simultaneously, thread 1 ( 310 ), thread 2 ( 320 ), thread 3 ( 330 ), and thread 4 ( 340 ).
  • Thread 1 consists of a data reception routine 302 that receives data from the hardware peripheral either via the operating system API 202 or directly from the hardware drivers.
  • Said data reception routine 302 may obtain said data by polling the hardware or alternatively via an interrupt mechanism that signals the thread whenever data is available from said hardware.
  • Said data reception software routine 302 receives said data and stores it in a shared memory buffer 303 .
  • Thread 2 consists of data transmission routine 304 that polls said shared buffer 303 .
  • said data transmission routine 304 retrieves said data. If necessary, data transmission routine 304 modifies said data to be acceptable to the circuit simulator 203 . Data transmission routine 304 then transmits said data to said circuit simulator via a PLI.
  • Thread 4 consists of a data reception routine 307 that retrieves data from circuit simulator 203 via a PLI. Thread 4 may obtain said data by polling the circuit simulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said circuit simulator. Said data reception routine 307 stores said received data in shared memory buffer 306 . Thread 3 consists of data transmission routine 305 that polls said shared buffer 306 . When data is available in said shared buffer 306 , said data reception routine 305 retrieves said data. If necessary, said data reception routine 305 modifies said data to be acceptable to the hardware peripheral. Said data reception routine 305 then transmits said data to said hardware peripheral either via the operating system API 202 or directly to the hardware drivers.
  • the SoftBridge program 200 has a stop routine 308 that takes input from the user in order to stop all executing threads of the program.
  • FIG. 4 shows another embodiment of the SoftBridge program 200 .
  • the SoftBridge program 200 has a start routine 301 that initiates the program and begins execution upon input from the user.
  • Said start routine initializes three independent threads that run simultaneously, thread 1 ( 410 ), thread 2 ( 420 ), and thread 3 ( 430 ).
  • Thread 1 consists of a data reception routine 302 that receives data from the hardware peripheral either via the operating system API 202 or directly from the hardware drivers.
  • Said data reception routine 302 may obtain said data by polling the hardware or alternatively via an interrupt mechanism that signals the thread whenever data is available from said hardware.
  • Said data reception software routine 302 receives said data and stores it in a shared memory buffer 303 .
  • Thread 2 consists of data transmission routine 304 that polls said shared buffer 303 .
  • said data transmission routine 304 retrieves said data. If necessary, data transmission routine 304 modifies said data to be acceptable to the circuit simulator 203 . Data transmission routine 304 then transmits said data to said circuit simulator via a PLI.
  • Thread 3 consists of a data reception routine 307 that retrieves data from circuit simulator 203 via a PLI and a data transmission routine 305 that transmits said data to the hardware peripheral either via the operating system API 202 or directly to the hardware drivers. Thread 3 may obtain said data by polling the circuit simulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said circuit simulator. Said data reception routine 307 sends said received data to said data reception routine 305 that modifies said data to be acceptable to the hardware peripheral, if necessary, then transmits said data to said hardware peripheral either via the operating system API 202 or directly to the hardware drivers.
  • This embodiment takes advantage of the fact that the circuit simulator 203 is running much slower than the software of the SoftBridge program 200 and that the hardware peripheral can receive data at a faster rate than the software can send it. Therefore there is only a single thread to retrieve data from the circuit simulator and send it to the hardware peripheral.
  • the SoftBridge program 200 can perform the entire operation of thread 3 without slowing down the circuit simulator or the hardware peripheral. Unlike the embodiment shown in FIG. 3 , this embodiment does not need a shared memory buffer between data reception routine 307 and data transmission routine 305 .
  • the SoftBridge program 200 has a stop routine 308 that takes input from the user in order to stop all executing threads of the program.
  • FIG. 5 shows another embodiment of the SoftBridge program 200 .
  • the SoftBridge program 200 has a start routine 301 that initiates the program and begins execution upon input from the user. Said start routine initializes two independent threads that run simultaneously, thread 1 ( 510 ), and thread 2 ( 520 ). Thread 1 consists of a data reception routine 302 and a data transmission routine 304 . Data reception routine 302 receives data from the hardware peripheral either via the operating system API 202 or directly from the hardware drivers. Said data reception routine 302 may obtain said data by polling the hardware or alternatively via an interrupt mechanism that signals the thread whenever data is available from said hardware.
  • Said data reception software routine 302 receives said data and sends it to said data transmission routine 304 that modifies said data to be acceptable to the circuit simulator 203 , if necessary, then transmits it to said circuit simulator via a PLI.
  • This embodiment takes advantage of the fact that the hardware peripheral sends data at a slower rate than the software of the SoftBridge program 200 can receive it. Therefore, there is only a single thread to retrieve data from the hardware peripheral and send it to the circuit simulator. In this embodiment, the SoftBridge program 200 can perform the entire operation of thread 1 without missing data from the hardware peripheral. Unlike the embodiment shown in FIG. 4 , this embodiment does not need a shared memory buffer between data reception routine 302 and data transmission routine 304 .
  • Thread 2 consists of a data reception routine 307 that retrieves data from circuit simulator 203 via a PLI and a data transmission routine 305 that transmits said data to the hardware peripheral either via the operating system API 202 or directly to the hardware drivers. Thread 2 may obtain said data by polling the circuit simulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said circuit simulator. Said data reception routine 307 sends said received data to said data reception routine 305 that modifies said data in order to be acceptable to the hardware peripheral, if necessary, then transmits said data to said hardware peripheral either via the operating system API 202 or directly to the hardware drivers.
  • the SoftBridge program 200 has a stop routine 308 that takes input from the user in order to stop all executing threads of the program.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

A system and method is described for connecting a logic circuit simulation to a hardware peripheral that includes a computer running software for communicating data to and from the hardware peripheral. The software transmits the data received from the hardware peripheral to the device being simulated by the logic circuit simulation. The computer also transmits the data received from the device being simulated by the electronic circuit simulation to the hardware peripheral. This allows the user to test the device being simulated using real hardware for input and output instead of simulated hardware.

Description

CROSS-REFERENCE TO RELATED APPLICATION
The present application is a reissue of U.S. patent application Ser. No. 10/158,648, entitled “Apparatus and Method for Connecting Hardware to a Circuit Simulation,” filed on May 31, 2002, now U.S. Pat. No. 7,266,490, issued Sep. 4, 2007, which is a continuation-in-part application of copending U.S. patent application, Ser. No. 09/751,573, entitled “Method for Connecting a Hardware Emulator to a Network”, filed on Dec. 28, 2000, now U.S. Patent 7,050,962, issued on May 23, 2006, which claims the benefit of Provisional Application No. 60/193,169, filed on Mar. 28, 2000.
BACKGROUND OF THE INVENTION
Prior to reducing an integrated circuit design to a form suitable for fabrication, the integrated circuit design is often simulated in software on a computer to allow the design to be optimized and debugged. Typically, using a hardware description language (e.g., Verilog), the circuit designer prepares a description of the integrated circuit, which is then compiled into a software model to be simulated on the computer (e.g., an engineering workstation).
When an integrated circuit that connects to peripheral hardware, such as an LCD display or a Universal Serial Bus (USB) port, is simulated, the peripheral hardware is modeled in the hardware description language and communication with the peripheral hardware is also simulated. However, such a model of the peripheral hardware does not behave completely accurately and correctly. There are often logical, electrical, or timing differences between the simulation model and the physical peripheral hardware. When the integrated circuit is manufactured and connected to the actual peripheral hardware, these problems will become apparent and the integrated circuit will often need to be redesigned to compensate for them.
SUMMARY OF THE INVENTION
The present invention allows a logic circuit simulator running on a host computer (e.g., a personal computer) and simulating a circuit (“simulated device”) to connect to a physical peripheral hardware device. The present invention provides a method and an apparatus for transferring data between a circuit simulation and the peripheral hardware device. In one embodiment, an interface software program also installed on said host computer is provided to handle communication between the operating system drivers for the peripheral hardware device and the simulated device. The peripheral hardware device can be, for example, a computer display monitor.
According to the present invention, data sent to a simulated device from a physical peripheral hardware device is received by the interface software and stored in buffers in the existing memory in the host computer. Said interface software in said host computer repackages the data into a second format for transmission to said simulated device. In one embodiment, the data from said physical peripheral hardware device is sent to the operating system of said host computer. Said interface software intercepts said data and examines it. If said data is intended for said simulated device, said interface software loads it into said data buffers, subsequently repackages said data into a second format for transmission to said simulated device and sends said repackaged data to the simulated device. If said data from said physical peripheral hardware device is not intended for said simulated device, said interface software program sends said data on to said host computer operating system.
Similarly, the interface software in the host computer repackages data received from the simulated device into proper format for transmission to the physical peripheral hardware device. Under this arrangement, the existing memory in the host computer is used to buffer data communicated between said simulated device and said physical peripheral hardware device. In one embodiment, the data from said simulated device is sent to the interface software program. If said data is intended for said physical peripheral hardware device, said interface software program repackages said data and sends said data to said host computer operating system for transmission to said physical peripheral hardware device. Said operating system is notified that said data is intended for said physical peripheral hardware device because said interface software program uses a specific application program interface (API) of the operating system used specifically to access said physical peripheral hardware device.
In one embodiment, the interface software of the host computer is implemented as a multithread program including four executing threads. One thread is a task that receives data from the physical peripheral hardware device and stores said received data in a first buffer. A second thread is a task that polls said first buffer for said received data. This second thread repackages said received data and sends said repackaged data via the simulation interface to the simulated device. A third thread is a task that receives data from said simulated device via said simulation interface and stores said received data in a second buffer. A fourth thread is a task that polls said second buffer for said data received from said simulated device. Said fourth thread repackages said data received from said simulated device and sends said repackaged data to said physical peripheral hardware device using an API of the operating system software of said host computer.
In another embodiment, the interface software of the host computer is implemented as a multithread program, as in the previous embodiment, except that the second buffer is eliminated and the third and fourth threads are combined into a single thread. In this embodiment, the tasks of the single thread receive data from the simulated device via the simulation interface, repackages said received data and sends said repackaged to said physical peripheral hardware device using an API of the operating system software of said host computer. This approach is possible because a circuit simulation runs at a much slower speed than the physical peripheral hardware device, such that data received from the simulated device can be repackaged and sent to the physical peripheral hardware device before the next data packet's arrival from the circuit simulation.
In yet another embodiment, the interface software of the host computer is implemented as a multithreaded program having, in one instance, two executing threads. One thread is a task that receives data from the physical peripheral hardware device, stores said received data in a buffer, retrieves said stored data for repackaging, and sends said repackaged data via a simulation interface to the simulated device. Another thread is a task that receives data from said simulated device via said simulation interface from said simulated device, repackages said data and sends said repackaged data to said physical peripheral hardware device using an API of the operating system software of said host computer.
Further features and advantages of various embodiments of the invention are described in the detailed description below, which is given by way of example only.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of the preferred embodiment of the invention, which, however, should not be taken to limit the invention to the specific embodiment but are for explanation and understanding only.
FIG. 1 shows a computer with various hardware peripherals including built-in peripherals and external peripherals.
FIG. 2 shows a block diagram of typical computer software including low-level hardware drivers, an operating system, application programs, and a user interface.
FIG. 3 is a block diagram showing the functions performed by SoftBridge program 200, in accordance with one embodiment of the present invention.
FIG. 4 is a block diagram showing the functions performed by SoftBridge program 200, in accordance with a second embodiment of the present invention.
FIG. 5 is a block diagram showing the functions performed by SoftBridge program 200, in accordance with a third embodiment of the present invention.
In the following detailed description, to simplify the description, like elements are provided like reference numerals.
DETAILED DESCRIPTION
Software that allows a logic circuit simulator running on a host computer (e.g., a personal computer) and simulating a circuit (“simulated device”) to connect to a physical peripheral hardware device is described. In the following description, numerous specific details are set forth, such as the peripheral interface, the operating system, the type of computer, etc., in order to provide a thorough understanding of the present invention. It will be obvious, however, to one skilled in the art that these specific details need not be used to practice the present invention. In other instances, well known structures, functions, and software programs have not been shown in detail in order not to unnecessarily obscure the present invention.
FIG. 1 shows a typical computer configuration that implements the present invention. The processor 101 connects via high-speed processor-system bus 120 to the cache controller 102 and the cache memory 103. Said cache controller 102 connects via a medium speed memory-system bus 130 to main memory 104 and bridge 105 as well as to high speed peripheral devices such as fast mass storage device 106, fast display 107, and other fast peripherals 108. Note that said processor 101 also connects directly via medium speed memory-system bus 130 to said high speed peripherals fast mass storage device 106, fast display 107, and other fast peripherals 108. Said bridge 105 acts to connect the medium speed memory-system bus 130 to low-speed system bus 140 which connects to slow peripherals slow display 109, keyboard 110, mouse 111, slow mass storage device 112, printer 113, and slow peripherals 114. All peripherals, fast or slow, are shown in shaded box 150. Note that peripherals may in fact be boards or chips that drive peripheral devices, but for the purposes of this invention, we do not differentiate between the chips or board that drives a peripheral and the peripheral itself.
FIG. 2 shows a block diagram of the software executing on processor 101. At the lowest level is the driver software for hardware peripherals 205. This software, usually supplied by the manufacturer of said peripherals allows computer operating system software 204 to access said peripherals without detailed knowledge of the hardware design or the operation of said peripherals. Said operating system also includes routines called hardware peripheral application program interfaces (APIs) 202 that allow application programs to indirectly access the hardware peripherals via said operating system. In this way, application programs can control the peripherals but the operating system can override said control or can allocate these peripherals to application programs according to particular priorities.
A circuit simulation program 203 runs at a higher level than the operating system and uses the operating system to communicate with the user to display information via a peripheral such as a monitor or a printer. Said simulation program also uses the operating system to get information from a user via the mouse or keyboard. The operating system 204 also allows said simulation 203 and other applications to be running simultaneously and allocates time and resources to all applications according to set priorities.
One embodiment of the invention is shown as SoftBridge program 200, an application program that runs on top of the operating system, which controls the computer resources allocated to it. The SoftBridge program 200 can communicate to the simulation 203 via a software interface called a programming language interface (PLI) 206.
Note that the SoftBridge program 200 can use the hardware peripheral APIs 202 to access the hardware peripherals indirectly. In some cases, to increase performance for example, it may be necessary for the SoftBridge program 200 to access the driver software 205 directly, bypassing the operating system 204 and the APIs provided by the operating system.
The user interface 201 is the part of the SoftBridge program 200 that allows the human user to enter information and control operation of the program 200. Said user interface 201 also gives results back to the human user.
In prior art, a circuit simulation of a device that drives a hardware peripheral would output raw data. An engineer would then look over the data and compare it manually to a specification for said hardware peripheral to determine whether the data is correct. This manual checking of data is a time consuming operation that is prone to human error and limits the amount of simulation that can be run because time in the development process must be allocated for humans to check the results. Another prior art method is to create a circuit simulation of the hardware peripheral (“simulated peripheral”) and have the simulated device drive the simulated peripheral and observe that the correct behavior occurs. This method requires that an engineer write a model for said hardware peripheral. Not only does this take time to develop said model, but the model itself is prone to human error because it may not be completely correct and may thus not accurately model the true behavior of the peripheral hardware. Because the circuit simulation software must now simulate not only the device that drives the software but also the peripheral hardware device being driven, the simulation software runs much slower.
In prior art, a simulated device that receives data from a hardware peripheral would need to have raw data written by an engineer and then used by the simulation software as stimuli for the device. This manual creation of data is a time consuming operation that is prone to human error and limits the amount of simulation that can be run because time in the development process must be allocated for humans to create the data. Another prior art method is to create a circuit simulation of the hardware peripheral and have the simulated peripheral drive the simulated device and observe that the behavior is correct. This method requires that an engineer write a model for the hardware peripheral. Not only does this take time to develop said model, but the model itself is prone to human error because it may not be completely correct and may thus not accurately model the true behavior of the peripheral hardware. Because the circuit simulation software must now simulate not only the device that drives the software but also the peripheral hardware device being driven, the simulation software runs much slower.
In other prior art, a hardware peripheral device is connected, pin by pin, to another hardware peripheral device called a hardware modeler interface, which is in turn connected to a host computer. Said host computer runs a circuit simulation of a device. Whenever said simulated device intends to stimulate said hardware peripheral, said simulation software notifies special hardware modeling software, which forces said hardware modeler interface to assert or deassert signals to said hardware peripheral according to the simulated device outputs. Similarly, whenever said hardware peripheral outputs change, said signals are sent to said hardware modeler interface, which notifies said hardware modeling software, which in turn notifies said simulation software, which stimulates said simulated device. This method requires very specialized software, the hardware modeling software, to interface between the simulation software and the hardware modeler interface. This hardware modeling software must continually be rewritten to be compatible with new operating systems, new host computers, or new simulation software. The hardware modeler interface is a costly, specialized piece of hardware that must physically be connected to the hardware peripheral. Said hardware modeler interface is limited to connecting to certain hardware peripheral devices by the type and size of the connectors that it has available. For example, to connect to an ISA card, said hardware modeler interface must have an ISA connector and to connect to a PCI card, said hardware modeler interface must have a PCI connector. To be able to connect to any kind of peripheral device would require said hardware modeler interface to comprise an extremely large circuit board with dozens of connectors, or consist of dozens of different boards for connecting to different peripheral hardware devices.
The present invention overcomes the limitations of the prior art by interfacing a real hardware peripheral to the circuit simulation of said device, taking advantage of standard software that is easily available and has already been fully tested. This standard software includes driver software and APIs that are written by the hardware peripheral manufacturer and are included in most standard operating systems. As shown in FIG. 3, data from the circuit simulation 203 of said device that is intended to drive said hardware peripheral is sent to the SoftBridge program 200 from the circuit simulation program PLI. The SoftBridge program 200 sends said data to the hardware peripheral either via the hardware peripheral API 202 of the operating system or directly to the hardware peripheral device drivers 205. Data from the hardware peripherals is retrieved by the SoftBridge program 200 either from the hardware peripheral API 202 of the operating system or directly from the hardware peripheral device drivers 205. The SoftBridge program 200 sends said data to the circuit simulation 203 via the circuit simulation program PLI.
FIG. 3 shows a block diagram of the SoftBridge program. In this embodiment, the SoftBridge program 200 has a start routine 301 that initiates the program and begins execution upon input from the user. Said start routine initializes four independent threads that run simultaneously, thread 1 (310), thread 2 (320), thread 3 (330), and thread 4 (340). Thread 1 consists of a data reception routine 302 that receives data from the hardware peripheral either via the operating system API 202 or directly from the hardware drivers. Said data reception routine 302 may obtain said data by polling the hardware or alternatively via an interrupt mechanism that signals the thread whenever data is available from said hardware. Said data reception software routine 302 receives said data and stores it in a shared memory buffer 303. Thread 2 consists of data transmission routine 304 that polls said shared buffer 303. When data is available in said shared buffer 303, said data transmission routine 304 retrieves said data. If necessary, data transmission routine 304 modifies said data to be acceptable to the circuit simulator 203. Data transmission routine 304 then transmits said data to said circuit simulator via a PLI.
Thread 4 consists of a data reception routine 307 that retrieves data from circuit simulator 203 via a PLI. Thread 4 may obtain said data by polling the circuit simulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said circuit simulator. Said data reception routine 307 stores said received data in shared memory buffer 306. Thread 3 consists of data transmission routine 305 that polls said shared buffer 306. When data is available in said shared buffer 306, said data reception routine 305 retrieves said data. If necessary, said data reception routine 305 modifies said data to be acceptable to the hardware peripheral. Said data reception routine 305 then transmits said data to said hardware peripheral either via the operating system API 202 or directly to the hardware drivers.
In this embodiment, the SoftBridge program 200 has a stop routine 308 that takes input from the user in order to stop all executing threads of the program.
FIG. 4 shows another embodiment of the SoftBridge program 200. In this embodiment, the SoftBridge program 200 has a start routine 301 that initiates the program and begins execution upon input from the user. Said start routine initializes three independent threads that run simultaneously, thread 1 (410), thread 2 (420), and thread 3 (430). Thread 1 consists of a data reception routine 302 that receives data from the hardware peripheral either via the operating system API 202 or directly from the hardware drivers. Said data reception routine 302 may obtain said data by polling the hardware or alternatively via an interrupt mechanism that signals the thread whenever data is available from said hardware. Said data reception software routine 302 receives said data and stores it in a shared memory buffer 303. Thread 2 consists of data transmission routine 304 that polls said shared buffer 303. When data is available in said shared buffer 303, said data transmission routine 304 retrieves said data. If necessary, data transmission routine 304 modifies said data to be acceptable to the circuit simulator 203. Data transmission routine 304 then transmits said data to said circuit simulator via a PLI.
Thread 3 consists of a data reception routine 307 that retrieves data from circuit simulator 203 via a PLI and a data transmission routine 305 that transmits said data to the hardware peripheral either via the operating system API 202 or directly to the hardware drivers. Thread 3 may obtain said data by polling the circuit simulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said circuit simulator. Said data reception routine 307 sends said received data to said data reception routine 305 that modifies said data to be acceptable to the hardware peripheral, if necessary, then transmits said data to said hardware peripheral either via the operating system API 202 or directly to the hardware drivers. This embodiment takes advantage of the fact that the circuit simulator 203 is running much slower than the software of the SoftBridge program 200 and that the hardware peripheral can receive data at a faster rate than the software can send it. Therefore there is only a single thread to retrieve data from the circuit simulator and send it to the hardware peripheral. In this embodiment, the SoftBridge program 200 can perform the entire operation of thread 3 without slowing down the circuit simulator or the hardware peripheral. Unlike the embodiment shown in FIG. 3, this embodiment does not need a shared memory buffer between data reception routine 307 and data transmission routine 305.
In this embodiment, the SoftBridge program 200 has a stop routine 308 that takes input from the user in order to stop all executing threads of the program.
FIG. 5 shows another embodiment of the SoftBridge program 200. In this embodiment, the SoftBridge program 200 has a start routine 301 that initiates the program and begins execution upon input from the user. Said start routine initializes two independent threads that run simultaneously, thread 1 (510), and thread 2 (520). Thread 1 consists of a data reception routine 302 and a data transmission routine 304. Data reception routine 302 receives data from the hardware peripheral either via the operating system API 202 or directly from the hardware drivers. Said data reception routine 302 may obtain said data by polling the hardware or alternatively via an interrupt mechanism that signals the thread whenever data is available from said hardware. Said data reception software routine 302 receives said data and sends it to said data transmission routine 304 that modifies said data to be acceptable to the circuit simulator 203, if necessary, then transmits it to said circuit simulator via a PLI. This embodiment takes advantage of the fact that the hardware peripheral sends data at a slower rate than the software of the SoftBridge program 200 can receive it. Therefore, there is only a single thread to retrieve data from the hardware peripheral and send it to the circuit simulator. In this embodiment, the SoftBridge program 200 can perform the entire operation of thread 1 without missing data from the hardware peripheral. Unlike the embodiment shown in FIG. 4, this embodiment does not need a shared memory buffer between data reception routine 302 and data transmission routine 304.
Thread 2 consists of a data reception routine 307 that retrieves data from circuit simulator 203 via a PLI and a data transmission routine 305 that transmits said data to the hardware peripheral either via the operating system API 202 or directly to the hardware drivers. Thread 2 may obtain said data by polling the circuit simulator or alternatively via an interrupt mechanism that signals the thread whenever data is available from said circuit simulator. Said data reception routine 307 sends said received data to said data reception routine 305 that modifies said data in order to be acceptable to the hardware peripheral, if necessary, then transmits said data to said hardware peripheral either via the operating system API 202 or directly to the hardware drivers.
In this embodiment, the SoftBridge program 200 has a stop routine 308 that takes input from the user in order to stop all executing threads of the program.
Various modifications and adaptations of the operations described here would be apparent to those skilled in the art based on the above disclosure. Many variations and modifications within the scope of the present SoftBridge program 200 are therefore possible. The present SoftBridge program 200 is set forth by the following claims.

Claims (60)

1. A method for communicating data between a simulation of an electronic device carried out by a program executing in a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device operating at a higher speed than said simulation, the method comprising:
receiving data from said hardware peripheral device using peripheral device interface software running on said computer;
transmitting said data received from said hardware peripheral device to said simulation through a programming language interface;
receiving data from said simulation through said programming language interface; and
transmitting said received data from said simulation to said hardware peripheral device using peripheral device interface software running on said host computer;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation is executed in a third thread, and said transmitting said data received from said simulation is executed in a fourth thread.
2. The method of claim 1, further comprising storing said received data from said hardware peripheral device in a first buffer in memory.
3. The method of claim 1, further comprising storing said received data from said simulation in a second buffer in memory.
4. The method of claim 2, further comprising changing the size of said first buffer at run time.
5. The method of claim 3, further comprising changing the size of said second buffer at run time.
6. The method of claim 1, further comprising keeping a record of said data received from said hardware peripheral device, said data transmitted to said simulation, said data received from said simulation, and said data transmitted to said hardware peripheral device.
7. The method of claim 1, further comprising recording the throughput of said data.
8. The method of claim 1, further comprising modifying said received data from said hardware peripheral device to make said data suitable for transmission to said simulation.
9. The method of claim 1, further comprising modifying said received data from said simulation to make said data suitable for transmission to said hardware peripheral device.
10. A method for communicating data between a simulation of an electronic device carried out by a program executing on a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the method comprising:
receiving data from said hardware peripheral device using peripheral device interface software running on said computer;
storing said data received from said hardware peripheral device in a first buffer;
retrieving said data stored in said first buffer;
modifying said retrieved data to make said data suitable for transmission to said simulation;
transmitting said data received from said hardware peripheral to said simulation through a programming language interface;
receiving data from said simulation through said programming language interface;
storing said data received from said simulation in a second buffer;
retrieving said data stored in said second buffer;
modifying said retrieved data to make said data suitable for transmission to said hardware peripheral device; and
transmitting said received data from said simulation to said hardware peripheral device using peripheral device interface software running on said host computer;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation is executed in a third thread, and said transmitting said data received from said simulation is executed in a fourth thread.
11. An apparatus for communicating data between a simulation of an electronic device carried out by a program executing in a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the apparatus comprising:
a memory;
computer instructions executable by said host computer for:
receiving data from said hardware peripheral device;
transmitting said data received from said hardware peripheral device to said electronic circuit simulation;
receiving data from said electronic circuit simulation; and
transmitting said data received from said electronic circuit simulation to said hardware peripheral device;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation is executed in a third thread, and said transmitting said data received from said simulation is executed in a fourth thread.
12. The apparatus of claim 11, further comprising:
a buffer in said memory; and
computer instructions executable by the computer for storing data received from said hardware peripheral device in said buffer.
13. The apparatus of claim 12, further comprising computer instructions executable by the computer for changing the size of said first buffer at run time.
14. The apparatus of claim 11 further comprising:
a buffer in said memory; and
computer instructions executable by the computer for storing data received from said electronic circuit simulation in said buffer.
15. The apparatus of claim 14, further comprising computer instructions executable by the computer for changing the size of said second buffer at run time.
16. The apparatus of claim 11, further comprising computer instructions executable by the computer for modifying said received data from said simulation to make said data suitable for transmission to said hardware peripheral device.
17. The apparatus of claim 11, further comprising computer instructions executable by the computer for modifying said received data from said hardware peripheral device to make said data suitable for transmission to said simulation.
18. The apparatus of claim 11, further comprising computer instructions executable by the computer for keeping a record of said data received from said hardware peripheral, said data transmitted to said simulation, said data received from said simulation, and said data transmitted to said hardware peripheral device.
19. The apparatus of claim 11, further comprising computer instructions executable by the computer for recording the throughput of said data.
20. An apparatus for communicating data between a simulation of an electronic device carried out by a program executing in a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the apparatus comprising:
a. a computer having a memory;
b. computer instructions executable by said host computer for:
receiving data from said hardware peripheral device using software running on said computer;
storing said data received from said hardware peripheral device in a first buffer in memory;
retrieving said data stored in said first buffer;
modifying said retrieved data to make said data suitable for transmission to said simulation;
transmitting said data received from said hardware peripheral device to said simulation through a programming language interface;
receiving data from said simulation through said programming language interface;
storing said data received from said simulation in a second buffer in memory;
retrieving said data stored in said second buffer;
modifying said retrieved data to make said data suitable for transmission to said hardware peripheral device; and
transmitting said received data from said simulation to said hardware peripheral device using software running on said host computer;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation is executed in a third thread, and said transmitting said data received from said simulation is executed in a fourth thread.
21. A computer readable medium having computer instructions executable in a host computer for communicating data between a simulation of an electronic device carried out in a program executing in said host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the instructions performing:
receiving data from said hardware peripheral device;
transmitting said data received from said hardware peripheral to said electronic circuit simulation;
receiving data from said electronic circuit simulation; and
transmitting said data received from said electronic circuit simulation to said hardware peripheral device;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation is executed in a third thread, and said transmitting said data received from said simulation is executed in a fourth thread.
22. The computer readable medium of claim 21, further comprising computer instructions for storing data received from said hardware peripheral device in a first buffer.
23. The computer readable medium of claim 22, further comprising computer instructions for changing the size of said first buffer at run time.
24. The computer readable medium of claim 21, further comprising computer instructions for storing data received from said electronic circuit simulation in a second buffer.
25. The computer readable medium of claim 24, further comprising computer instructions for changing the size of said second buffer at run time.
26. The computer readable medium of claim 21, further comprising computer instructions for modifying said received data from said simulation to make said data suitable for transmission to said hardware peripheral device.
27. The computer readable medium of claim 21, further comprising computer instructions for modifying said received data from said hardware peripheral device to make said data suitable for transmission to said simulation.
28. The computer readable medium of claim 21, further comprising computer instructions for keeping a record of said data received from said hardware peripheral device, said data transmitted to said simulation, said data received from said simulation, and said data transmitted to said hardware peripheral device.
29. The computer readable medium of claim 21, further comprising computer instructions for recording the throughput of said data.
30. A computer readable medium having computer instructions for communicating data between a simulation of an electronic device carried out by a program executing in a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the instructions performing:
receiving data from said hardware peripheral device using peripheral device interface software running on said computer;
storing said data received from said hardware peripheral in a first buffer in memory;
retrieving said data stored in said first buffer;
modifying said retrieved data to make said data suitable for transmission to said simulation;
transmitting said data received from said hardware peripheral device to said simulation through a programming language interface;
receiving data from said simulation through said programming language interface;
storing said data received from said simulation in a second buffer in memory;
retrieving said data stored in said second buffer;
modifying said retrieved data to make said data suitable for transmission to said hardware peripheral device; and
transmitting said received data from said simulation to said hardware peripheral device using peripheral device interface software running on said host computer;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation is executed in a third thread, and said transmitting said data received from said simulation is executed in a fourth thread.
31. A method for communicating data between a simulation of an electronic device carried out by a program executing in a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device operating at a higher speed than said simulation, the method comprising:
receiving data from said hardware peripheral device using peripheral device interface software running on said computer;
transmitting said data received from said hardware peripheral device to said simulation through a programming language interface;
receiving data from said simulation through said programming language interface; and
transmitting said received data from said simulation to said hardware peripheral device using peripheral device interface software running on said host computer;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation and said transmitting said data received from said simulation are executed in a third thread.
32. The method of claim 31, further comprising storing said received data from said hardware peripheral device in a first buffer in memory.
33. The method of claim 31, further comprising storing said received data from said simulation in a second buffer in memory.
34. The method of claim 32, further comprising changing the size of said first buffer at run time.
35. The method of claim 33, further comprising changing the size of said second buffer at run time.
36. The method of claim 31, further comprising keeping a record of said data received from said hardware peripheral device, said data transmitted to said simulation, said data received from said simulation, and said data transmitted to said hardware peripheral device.
37. The method of claim 31, further comprising recording the throughput of said data.
38. The method of claim 31, further comprising modifying said received data from said hardware peripheral device to make said data suitable for transmission to said simulation.
39. The method of claim 31, further comprising modifying said received data from said simulation to make said data suitable for transmission to said hardware peripheral device.
40. An apparatus for communicating data between a simulation of an electronic device carried out by a program executing in a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the apparatus comprising:
a. a memory;
b. computer instructions executable by said host computer for:
receiving data from said hardware peripheral device;
transmitting said data received from said hardware peripheral device to said electronic circuit simulation;
receiving data from said electronic circuit simulation; and
transmitting said data received from said electronic circuit simulation to said hardware peripheral device;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation and said transmitting said data received from said simulation are executed in a third thread.
41. The apparatus of claim 40, further comprising:
a. a buffer in said memory; and
b. computer instructions executable by the computer for storing data received from said hardware peripheral device in said buffer.
42. The apparatus of claim 41, further comprising computer instructions executable by the computer for changing the size of said first buffer at run tune.
43. The apparatus of claim 40 further comprising:
a. a buffer in said memory; and
b. computer instructions executable by the computer for storing data received from said electronic circuit simulation in said buffer.
44. The apparatus of claim 43, further comprising computer instructions executable by the computer for changing the size of said second buffer at run time.
45. The apparatus of claim 40, further comprising computer instructions executable by the computer for modifying said received data from said simulation to make said data suitable for transmission to said hardware peripheral device.
46. The apparatus of claim 40, further comprising computer instructions executable by the computer for modifying said received data from said hardware peripheral device to make said data suitable for transmission to said simulation.
47. The apparatus of claim 40, further comprising computer instructions executable by the computer for keeping a record of said data received from said hardware peripheral, said data transmitted to said simulation, said data received from said simulation, and said data transmitted to said hardware peripheral device.
48. The apparatus of claim 40, further comprising computer instructions executable by the computer for recording the throughput of said data.
49. A computer readable medium having computer instructions executable in a host computer for communicating data between a simulation of an electronic device carried out in a program executing in said host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the instructions performing:
receiving data from said hardware peripheral device;
transmitting said data received from said hardware peripheral to said electronic circuit simulation;
receiving data from said electronic circuit simulation; and
transmitting said data received from said electronic circuit simulation to said hardware peripheral device;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation and said transmitting said data received from said simulation are executed in a third thread.
50. The computer readable medium of claim 49, further comprising computer instructions for storing data received from said hardware peripheral device in a first buffer.
51. The computer readable medium of claim 50, further comprising computer instructions for changing the size of said first buffer at run time.
52. The computer readable medium of claim 49, further comprising computer instructions for storing data received from said electronic circuit simulation in a second buffer.
53. The computer readable medium of claim 52, further comprising computer instructions for changing the size of said second buffer at run time.
54. The computer readable medium of claim 49, further comprising computer instructions for modifying said received data from said simulation to make said data suitable for transmission to said hardware peripheral device.
55. The computer readable medium of claim 49, further comprising computer instructions for modifying said received data from said hardware peripheral device to make said data suitable for transmission to said simulation.
56. The computer readable medium of claim 49, further comprising computer instructions for keeping a record of said data received from said hardware peripheral device, said data transmitted to said simulation, said data received from said simulation, and said data transmitted to said hardware peripheral device.
57. The computer readable medium of claim 49, further comprising computer instructions for recording the throughput of said data.
58. A method for communicating data between a simulation of an electronic device carried out by a program executing on a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the method comprising:
receiving data from said hardware peripheral device using peripheral device interface software running on said computer;
storing said data received from said hardware peripheral device in a first buffer;
retrieving said data stored in said first buffer;
modifying said retrieved data to make said data suitable for transmission to said simulation;
transmitting said data received from said hardware peripheral to said simulation through a programming language interface;
receiving data from said simulation through said programming language interface;
storing said data received from said simulation in a second buffer;
retrieving said data stored in said second buffer;
modifying said retrieved data to make said data suitable for transmission to said hardware peripheral device; and
transmitting said received data from said simulation to said hardware peripheral device using peripheral device interface software running on said host computer;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation and said transmitting said data received from said simulation are executed in a third thread.
59. An apparatus for communicating data between a simulation of an electronic device carried out by a program executing in a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the apparatus comprising:
a. a computer having a memory; and
b. computer instructions executable by said host computer for:
receiving data from said hardware peripheral device using software running on said computer;
storing said data received from said hardware peripheral device in a first buffer in memory;
retrieving said data stored in said first buffer;
modifying said retrieved data to make said data suitable for transmission to said simulation;
transmitting said data received from said hardware peripheral device to said simulation through a programming language interface;
receiving data from said simulation through said programming language interface;
storing said data received from said simulation in a second buffer in memory;
retrieving said data stored in said second buffer;
modifying said retrieved data to make said data suitable for transmission to said hardware peripheral device; and
transmitting said received data from said simulation to said hardware peripheral device using software running on said host computer;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation and said transmitting said data received from said simulation are executed in a third thread.
60. A computer readable medium having computer instructions for communicating data between a simulation of an electronic device carried out by a program executing in a host computer and a hardware peripheral device attached to said host computer, said hardware peripheral device running at a higher speed than said simulation, the instructions performing:
receiving data from said hardware peripheral device using peripheral device interface software running on said computer;
storing said data received from said hardware peripheral in a first buffer in memory;
retrieving said data stored in said first buffer;
modifying said retrieved data to make said data suitable for transmission to said simulation;
transmitting said data received from said hardware peripheral device to said simulation through a programming language interface;
receiving data from said simulation through said programming language interface;
storing said data received from said simulation in a second buffer in memory;
retrieving said data stored in said second buffer;
modifying said retrieved data to make said data suitable for transmission to said hardware peripheral device; and
transmitting said received data from said simulation to said hardware peripheral device using peripheral device interface software running on said host computer;
wherein said receiving data from said hardware peripheral device is executed in a first thread, said transmitting said data received from said hardware peripheral device is executed in a second thread, said receiving data from said simulation and said transmitting said data received from said simulation are executed in a third thread.
US12/481,943 2000-03-28 2009-06-10 Apparatus and method for connecting hardware to a circuit simulation Expired - Lifetime USRE42227E1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/481,943 USRE42227E1 (en) 2000-03-28 2009-06-10 Apparatus and method for connecting hardware to a circuit simulation

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US19316900P 2000-03-28 2000-03-28
US09/751,573 US7050962B2 (en) 2000-03-28 2000-12-28 Method for connecting a hardware emulator to a network
US10/158,648 US7266490B2 (en) 2000-12-28 2002-05-31 Apparatus and method for connecting hardware to a circuit simulation
US12/481,943 USRE42227E1 (en) 2000-03-28 2009-06-10 Apparatus and method for connecting hardware to a circuit simulation

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/158,648 Reissue US7266490B2 (en) 2000-03-28 2002-05-31 Apparatus and method for connecting hardware to a circuit simulation

Publications (1)

Publication Number Publication Date
USRE42227E1 true USRE42227E1 (en) 2011-03-15

Family

ID=37856390

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/481,943 Expired - Lifetime USRE42227E1 (en) 2000-03-28 2009-06-10 Apparatus and method for connecting hardware to a circuit simulation

Country Status (1)

Country Link
US (1) USRE42227E1 (en)

Citations (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4590581A (en) 1983-05-09 1986-05-20 Valid Logic Systems, Inc. Method and apparatus for modeling systems of complex circuits
US4635218A (en) 1983-05-09 1987-01-06 Valid Logic Systems Method for simulating system operation of static and dynamic circuit devices
US4744084A (en) 1986-02-27 1988-05-10 Mentor Graphics Corporation Hardware modeling system and method for simulating portions of electrical circuits
US5299313A (en) 1992-07-28 1994-03-29 3Com Corporation Network interface with host independent buffer management
US5303347A (en) 1991-12-27 1994-04-12 Digital Equipment Corporation Attribute based multiple data structures in host for network received traffic
US5307459A (en) 1992-07-28 1994-04-26 3Com Corporation Network adapter with host indication optimization
US5479355A (en) 1993-09-14 1995-12-26 Hyduke; Stanley M. System and method for a closed loop operation of schematic designs with electrical hardware
US5740448A (en) 1995-07-07 1998-04-14 Sun Microsystems, Inc. Method and apparatus for exclusive access to shared data structures through index referenced buffers
US5748875A (en) 1996-06-12 1998-05-05 Simpod, Inc. Digital logic simulation/emulation system
US5748806A (en) 1992-10-15 1998-05-05 Adaptec, Inc. Deskew circuit in a host interface circuit
US5761486A (en) 1995-08-21 1998-06-02 Fujitsu Limited Method and apparatus for simulating a computer network system through collected data from the network
US5822520A (en) * 1995-12-26 1998-10-13 Sun Microsystems, Inc. Method and apparatus for building network test packets
US5848236A (en) * 1996-03-22 1998-12-08 Sun Microsystems, Inc. Object-oriented development framework for distributed hardware simulation
US5850345A (en) 1996-01-29 1998-12-15 Fuji Xerox Co., Ltd. Synchronous distributed simulation apparatus and method
US5881269A (en) 1996-09-30 1999-03-09 International Business Machines Corporation Simulation of multiple local area network clients on a single workstation
US5889954A (en) 1996-12-20 1999-03-30 Ericsson Inc. Network manager providing advanced interconnection capability
US5907696A (en) 1996-07-03 1999-05-25 Cabletron Systems, Inc. Network device simulator
US5963726A (en) 1998-03-20 1999-10-05 National Instruments Corporation Instrumentation system and method including an improved driver software architecture
US6047387A (en) * 1997-12-16 2000-04-04 Winbond Electronics Corp. Simulation system for testing and displaying integrated circuit's data transmission function of peripheral device
US6108309A (en) 1997-12-08 2000-08-22 Mci Communications Corporation SONET network element simulator
US6141689A (en) * 1993-10-01 2000-10-31 International Business Machines Corp. Method and mechanism for allocating switched communications ports in a heterogeneous data processing network gateway
US6151567A (en) * 1994-05-27 2000-11-21 Hamilton Sundstrand Corporation Data communication analysis and simulation tool
US6202044B1 (en) 1997-06-13 2001-03-13 Simpod, Inc, Concurrent hardware-software co-simulation
US6230114B1 (en) * 1999-10-29 2001-05-08 Vast Systems Technology Corporation Hardware and software co-simulation including executing an analyzed user program
US6243833B1 (en) 1998-08-26 2001-06-05 International Business Machines Corporation Apparatus and method for self generating error simulation test data from production code
US6263302B1 (en) * 1999-10-29 2001-07-17 Vast Systems Technology Corporation Hardware and software co-simulation including simulating the cache of a target processor
US6307877B1 (en) 1995-10-04 2001-10-23 Imec Programmable modem apparatus for transmitting and receiving digital data, design method and use method for the modem
US6324492B1 (en) * 1998-01-20 2001-11-27 Microsoft Corporation Server stress testing using multiple concurrent client simulation
US6345242B1 (en) * 1996-03-22 2002-02-05 Sun Microsystems, Inc. Synchronization mechanism for distributed hardware simulation
US6347388B1 (en) 1997-06-03 2002-02-12 Verisity Ltd. Method and apparatus for test generation during circuit design
US6389379B1 (en) * 1997-05-02 2002-05-14 Axis Systems, Inc. Converification system and method
US6405145B1 (en) 1998-03-20 2002-06-11 National Instruments Corporation Instrumentation system and method which performs instrument interchangeability checking
US20020101824A1 (en) * 2000-03-28 2002-08-01 Ziedman Robert M. System and method for connecting a logic circuit simulation to a network
US6560641B1 (en) * 2000-03-29 2003-05-06 Unisys Corporation System, method, and adapter card for remote console emulation including remote control of a peripheral device
US6757367B1 (en) 1999-09-20 2004-06-29 Broadcom Corporation Packet based network exchange with rate synchronization
US20040143655A1 (en) 1998-06-15 2004-07-22 Narad Charles E. Accessing transmission control protocol (TCP) segments
US20040148610A1 (en) 1999-01-19 2004-07-29 William Tsun Methods, systems and computer program products for monitoring a task on a computer
US6772107B1 (en) * 1999-11-08 2004-08-03 J.D. Edwards World Source Company System and method for simulating activity on a computer network
US6850577B2 (en) 1999-09-20 2005-02-01 Broadcom Corporation Voice and data exchange over a packet based network with timing recovery
US6862635B1 (en) 1998-11-13 2005-03-01 Cray Inc. Synchronization techniques in a multithreaded environment
US6904110B2 (en) 1997-07-31 2005-06-07 Francois Trans Channel equalization system and method

Patent Citations (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4590581A (en) 1983-05-09 1986-05-20 Valid Logic Systems, Inc. Method and apparatus for modeling systems of complex circuits
US4635218A (en) 1983-05-09 1987-01-06 Valid Logic Systems Method for simulating system operation of static and dynamic circuit devices
US4590581B1 (en) 1983-05-09 1987-06-09
US4744084A (en) 1986-02-27 1988-05-10 Mentor Graphics Corporation Hardware modeling system and method for simulating portions of electrical circuits
US5303347A (en) 1991-12-27 1994-04-12 Digital Equipment Corporation Attribute based multiple data structures in host for network received traffic
US5299313A (en) 1992-07-28 1994-03-29 3Com Corporation Network interface with host independent buffer management
US5307459A (en) 1992-07-28 1994-04-26 3Com Corporation Network adapter with host indication optimization
US5748806A (en) 1992-10-15 1998-05-05 Adaptec, Inc. Deskew circuit in a host interface circuit
US5838950A (en) 1992-10-15 1998-11-17 Adaptec, Inc. Method of operation of a host adapter integrated circuit
US5479355A (en) 1993-09-14 1995-12-26 Hyduke; Stanley M. System and method for a closed loop operation of schematic designs with electrical hardware
US6141689A (en) * 1993-10-01 2000-10-31 International Business Machines Corp. Method and mechanism for allocating switched communications ports in a heterogeneous data processing network gateway
US6151567A (en) * 1994-05-27 2000-11-21 Hamilton Sundstrand Corporation Data communication analysis and simulation tool
US5740448A (en) 1995-07-07 1998-04-14 Sun Microsystems, Inc. Method and apparatus for exclusive access to shared data structures through index referenced buffers
US5761486A (en) 1995-08-21 1998-06-02 Fujitsu Limited Method and apparatus for simulating a computer network system through collected data from the network
US20020067757A1 (en) 1995-10-04 2002-06-06 Lieven Philips Programmable modem apparatus for transmitting and receiving digital data, design method and use method for the modem
US6898233B2 (en) 1995-10-04 2005-05-24 Imec Vzw Programmable modem apparatus for transmitting and receiving digital data, design method and use method for the modem
US6597727B2 (en) 1995-10-04 2003-07-22 Imec Vzw Programmable modem apparatus for transmitting and receiving digital data, design method and use method for the modem
US6307877B1 (en) 1995-10-04 2001-10-23 Imec Programmable modem apparatus for transmitting and receiving digital data, design method and use method for the modem
US5822520A (en) * 1995-12-26 1998-10-13 Sun Microsystems, Inc. Method and apparatus for building network test packets
US5850345A (en) 1996-01-29 1998-12-15 Fuji Xerox Co., Ltd. Synchronous distributed simulation apparatus and method
US5848236A (en) * 1996-03-22 1998-12-08 Sun Microsystems, Inc. Object-oriented development framework for distributed hardware simulation
US6345242B1 (en) * 1996-03-22 2002-02-05 Sun Microsystems, Inc. Synchronization mechanism for distributed hardware simulation
US5748875A (en) 1996-06-12 1998-05-05 Simpod, Inc. Digital logic simulation/emulation system
US5907696A (en) 1996-07-03 1999-05-25 Cabletron Systems, Inc. Network device simulator
US5881269A (en) 1996-09-30 1999-03-09 International Business Machines Corporation Simulation of multiple local area network clients on a single workstation
US5889954A (en) 1996-12-20 1999-03-30 Ericsson Inc. Network manager providing advanced interconnection capability
US6389379B1 (en) * 1997-05-02 2002-05-14 Axis Systems, Inc. Converification system and method
US6347388B1 (en) 1997-06-03 2002-02-12 Verisity Ltd. Method and apparatus for test generation during circuit design
US6202044B1 (en) 1997-06-13 2001-03-13 Simpod, Inc, Concurrent hardware-software co-simulation
US6904110B2 (en) 1997-07-31 2005-06-07 Francois Trans Channel equalization system and method
US6108309A (en) 1997-12-08 2000-08-22 Mci Communications Corporation SONET network element simulator
US6047387A (en) * 1997-12-16 2000-04-04 Winbond Electronics Corp. Simulation system for testing and displaying integrated circuit's data transmission function of peripheral device
US6324492B1 (en) * 1998-01-20 2001-11-27 Microsoft Corporation Server stress testing using multiple concurrent client simulation
US5963726A (en) 1998-03-20 1999-10-05 National Instruments Corporation Instrumentation system and method including an improved driver software architecture
US6405145B1 (en) 1998-03-20 2002-06-11 National Instruments Corporation Instrumentation system and method which performs instrument interchangeability checking
US6418392B1 (en) 1998-03-20 2002-07-09 National Instruments Corporation System and method for simulating operations of an instrument
US20040143655A1 (en) 1998-06-15 2004-07-22 Narad Charles E. Accessing transmission control protocol (TCP) segments
US6243833B1 (en) 1998-08-26 2001-06-05 International Business Machines Corporation Apparatus and method for self generating error simulation test data from production code
US6279122B1 (en) 1998-08-26 2001-08-21 International Business Machines Corporation Apparatus and method for self generating error simulation test data from production code
US6862635B1 (en) 1998-11-13 2005-03-01 Cray Inc. Synchronization techniques in a multithreaded environment
US20040148610A1 (en) 1999-01-19 2004-07-29 William Tsun Methods, systems and computer program products for monitoring a task on a computer
US6850577B2 (en) 1999-09-20 2005-02-01 Broadcom Corporation Voice and data exchange over a packet based network with timing recovery
US6757367B1 (en) 1999-09-20 2004-06-29 Broadcom Corporation Packet based network exchange with rate synchronization
US6584436B2 (en) 1999-10-29 2003-06-24 Vast Systems Technology, Inc. Hardware and software co-simulation including executing an analyzed user program
US6230114B1 (en) * 1999-10-29 2001-05-08 Vast Systems Technology Corporation Hardware and software co-simulation including executing an analyzed user program
US6263302B1 (en) * 1999-10-29 2001-07-17 Vast Systems Technology Corporation Hardware and software co-simulation including simulating the cache of a target processor
US6772107B1 (en) * 1999-11-08 2004-08-03 J.D. Edwards World Source Company System and method for simulating activity on a computer network
US20020101824A1 (en) * 2000-03-28 2002-08-01 Ziedman Robert M. System and method for connecting a logic circuit simulation to a network
US6560641B1 (en) * 2000-03-29 2003-05-06 Unisys Corporation System, method, and adapter card for remote console emulation including remote control of a peripheral device

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Larkshman "The Performance of TCPIIP for the Network with High Bandwidth-Delay Products and Random Loss," IEEE/ACM Transaction on Networking, vol. 5, No. 3, Jun. 1997, pp. 336-350.
Wesley W. Chu and M. Y. Elsanadidi, "Simulation Studies of the Behavior of Multihop Broadcast," ACM, 0-89791-089-3/83/0300-0170, 1983, pp. 170-177.

Similar Documents

Publication Publication Date Title
US7835897B2 (en) Apparatus and method for connecting hardware to a circuit simulation
KR101035832B1 (en) Simulation circuit of pci express endpoint and downstream port for a pci express switch
US8327039B2 (en) Integrated DMA processor and PCI express switch for a hardware-based functional verification system
US8473661B2 (en) System and method for providing multi-process protection using direct memory mapped control registers
US7917348B2 (en) Method of switching external models in an automated system-on-chip integrated circuit design verification system
US8566644B1 (en) System and method for debugging a target computer using SMBus
US6678625B1 (en) Method and apparatus for a multipurpose configurable bus independent simulation bus functional model
US5715433A (en) Dynamic software model for emulating hardware
US6110218A (en) Generation of multiple simultaneous random test cycles for hardware verification of multiple functions of a design under test
US20070204246A1 (en) Method and system for logic verification using mirror interface
JP2003036284A (en) Software and hardware simulation method
US20020178320A1 (en) Method and architecture for accessing hardware devices in computer system and the chipset thereof
US20070100598A1 (en) Apparatus and method for connecting a hardware emulator to a computer peripheral
CN106649021B (en) PCIe is from equipment testing device
US7225288B2 (en) Extended host controller test mode support for use with full-speed USB devices
US7437282B2 (en) Method and apparatus to provide alternative stimulus to signals internal to a model actively running on a logic simulation hardware emulator
US7319947B1 (en) Method and apparatus for performing distributed simulation utilizing a simulation backplane
US10664637B2 (en) Testbench restoration based on capture and replay
US20050144436A1 (en) Multitasking system level platform for HW/SW co-verification
CN114330176A (en) Chip verification method and device, electronic equipment and storage medium
US6842883B2 (en) Application of co-verification tools to the testing of IC designs
US6892154B1 (en) Method and apparatus for developing multiple test cases from a base test case
US6868545B1 (en) Method for re-using system-on-chip verification software in an operating system
USRE42227E1 (en) Apparatus and method for connecting hardware to a circuit simulation
US7447618B2 (en) Method and system for ASIC simulation

Legal Events

Date Code Title Description
AS Assignment

Owner name: IONIPAS TRANSFER COMPANY, LLC, DELAWARE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ZEIDMAN, ROBERT M.;REEL/FRAME:023904/0979

Effective date: 20080609

AS Assignment

Owner name: ZEIDMAN, ROBERT, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ZEIDMAN TECHNOLOGIES, INC.;REEL/FRAME:025477/0121

Effective date: 20070228

Owner name: ZEIDMAN TECHNOLOGIES, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ZEIDMAN, ROBERT M.;REEL/FRAME:025476/0929

Effective date: 20060522

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: OL SECURITY LIMITED LIABILITY COMPANY, DELAWARE

Free format text: MERGER;ASSIGNOR:IONIPAS TRANSFER COMPANY, LLC;REEL/FRAME:037588/0272

Effective date: 20150826

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12

AS Assignment

Owner name: INTELLECTUAL VENTURES ASSETS 130 LLC, DELAWARE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:OL SECURITY LIMITED LIABILITY COMPANY;REEL/FRAME:050886/0662

Effective date: 20191030

AS Assignment

Owner name: COMMWORKS SOLUTIONS, LLC, GEORGIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTELLECTUAL VENTURES ASSETS 130 LLC;REEL/FRAME:051463/0026

Effective date: 20191115

AS Assignment

Owner name: UNWIRED SOLUTIONS, INC., CALIFORNIA

Free format text: LICENSE;ASSIGNOR:COMMWORKS SOLUTIONS, LLC;REEL/FRAME:054443/0958

Effective date: 20200918

AS Assignment

Owner name: UNWIRED BROADBAND, INC., CALIFORNIA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE NAME PREVIOUSLY RECORDED AT REEL: 054443 FRAME: 0958. ASSIGNOR(S) HEREBY CONFIRMS THE LICENSE;ASSIGNOR:COMMWORKS SOLUTIONS, LLC;REEL/FRAME:056981/0631

Effective date: 20200918

Owner name: UNWIRED BROADBAND, INC., CALIFORNIA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE NAME PREVIOUSLY RECORDED AT REEL: 054443 FRAME: 0958. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:COMMWORKS SOLUTIONS, LLC;REEL/FRAME:056981/0631

Effective date: 20200918

AS Assignment

Owner name: UNWIRED BROADBAND, INC., CALIFORNIA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE THE NATURE OF CONVEYANCE PREVIOUSLY RECORDED AT REEL: 056981 FRAME: 0631. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:COMMWORKS SOLUTIONS, LLC;REEL/FRAME:059907/0563

Effective date: 20200918