m
`
`0
`
`
`
`
`5338993 '
`
`IIIIIIIIIIIIIIIIIII
`:
`PATENT? 999 mg"
`
`>
`
`,
`
`\_
`g
`
`
`I
`
`
`
`:5
`15%;“3/5664”
`
`
`
`
`VEIEEIFFREY .J'u
`
`3%
`
`fix
`
`EILJI‘JZA. EEQVELHTUN,
`
`BF?“
`
`.
`
`V fl: =t=l:2l:l.I\IT I N E‘_1 I N515
`VERIFIEB'
`
`[1' 91-929: :9:
`
`:9.-
`
`:4s:
`
`:9: :9: :9:
`
`:9:
`
`:9:
`
`:9: :9: :t: :9: :9:
`
`:9:
`
`:9:
`
`:+: 4:39; :t: :9:
`
`9mm. /‘
`
`
`
`LVINMQE; " ’-
`
`
`
`
`:1
`I
`
`pi
`
`
`1+: :{zFUREE EmfF-Ez'f Q]:- F..L l I”a1 I‘ IJNC; H: :t: 7+: 1}: :I: :t: :I: :5: :I: :t: :Il:
`\{EFt I F I E1}
`‘
`
`
`
`:‘,:
`
`i
`
`.9
`
`\
`
`\«._
`
`.A
`
`I
`
`FDREIGN FILING LICENEE HRQNTE“ “Hf I’IF
`
`
`Foreign priority chimed
`L] yes
`"'
`
`
`
`E] year
`if
`35 USC 119 oondmnnsmet
`
`
`
`I
`
`Examln
`» Verified nodAdu-Iowledgad
`In
`.,
`L SEEK: AND BERRY
`533:”:
`IZZIIILLJMEIIR CENTER
`:3
`g ‘_ SEPITTLE we 93134—79392
`
`FAISLED
`
`STATETEOH SHEET
`COUNTRY DRWG:
`
`
`***$* 3.
`
`CLAIMS
`
`INDEF.
`CLAIMS
`
`
`RECEIVED
`
`'
`I": '
`
`ATTORNEYS
`DOCKET NO.
`'
`II I“; ’7? 9-? i"!
`
`'
`
`”
`
`I
`.
`
`F
`
`
`
`I ENE-ITEM 9ND ME"T’I~~IL‘JE- FUR SIMULIEIT IEIN IIIF IZEIIV'IF‘L..ET|§F'I'
`‘ HfitFfii-‘INFIRE PINE» ENFTNF‘IHE INTERAITFIUI‘G
`
`
`
`
`53‘1”
`
`
`
`.ICIIIVIHLI‘JIIKIII—Ci
`
`, u.
`
`EFT. oscouwmnam—PTOMGL (name-94)-
`
`
`
`
`
`
` PARTS OFA-‘LICATION _ ,_ L
`.
`lack
`
`FILED SEP- 'ATELY
`“
`Au'Ica'fions
`amlner
`-
`CLAIMS ALLOWED
`
` JEROME V WQJ. kql
`
`
`
`
`
`WARNING: The Information disclosed herein may be rsstrictég. Unauthorized disclosure may be
`
`by the United States Code Tltla 35 Sections 1212.181 and 368 Possession outside
`Patent a. Trademark OfiioeIs restricted to authofized employees and contractotsonly.
`
`Inhibited
`a U5
`
`Assistant E aminer
`
`1
`TZOPQTZT 1009
`
`
`l
`SYNOPSYS 1009
`IEARET“
`
`I” '
`
`_
`
`
`
`

`

`
`
`
`
`—a.a
`
`
`1
`PATENT APPLICATION .
`1|||1l1|||||||||||1||11111ll|||l|1||1|||1|ll
`mflSSfiGfifl1
`CONTENTS‘
`
` .
`'-
`'
`» 'N
`APPROVEDFOHUGENSr: I
`mm;
`
`
`1
`
`,
`
`“waved
`
`
`
`13.
`
`Formal Drawins
`
`shts set
`
`
`
`18.
`
`PTO Grant NOV 1 7 1998
`
`
`
`
`
`
`
`
`2
`
`(FRONT)
`
`TZOPQTZT 1009
`
`

`

`PATENT APPLICATION SERIAL NO.
`
`06/566401
`
`U.S. DEPARTMENT OF COMMERCE
`PATENT AND TRADEMARK OFFICE
`FEE RECORD SHEET
`
`PTO-1556
`(5/87)
`
`3
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`BAR CODE LABEL
`
`lilllllllllllilllllllllllllillllillllllllilllllll
`
`,
`
`PATENT APPLICATION
`
`SERIAL NUMBER
`
`08/566,401
`
`FILING DATE _
`
`12/01/95
`
`GROUP ART UNIT
`
`2317
`
`GEOFFREY J. BUNZA, BEAVERTON, OR.
`
`APPLICANT
`
`**CONTINUING DATA*********************
`VERIFIED
`
`**FOREIGN/PCT APPLICATIONS***** *******
`VERIFIED
`
` 4
`
`that annexed hereto is a true co y fr9m_ the rqcords of the United States
`This is to certi
`Patent and Tra emark Office of the application w Ich Is Identified above.
`By authority of the
`COMMISSIONER OF PATENTS AND TRADEMARKS
`
`FOREIGN FILING LICENSE GRANTED 05/20/96
`
`***** SMALL ENTITY *****
`
`SHEETS
`DRAWING
`
`11
`
`SEED AND BERRY
`6300 COLUMBIA CENTER
`SEATTLE WA 98104—7092
`
`ADDRESS
`
`FILING FEE
`RECEIVED
`
`ATTORNEY DOCKET NO.
`
`$980.00
`
`120079.401
`
`SYSTEM AND METHOD FOR SIMULATION OF COMPUTER SYSTEMS COMBINING
`HARDWARE AND SOFTWARE INTERACTION
`
`Data
`
`_
`
`Certifying Officer
`
`4
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`
`
`BOX PATENT APPLICATION
`ASSISTANT COMMISSIONER FOR PATENTS
`WASHINGTON DC 20231
`Sir:
`
`SEED and BERRY
`6300 Columbia Center
`Seattle, WA 98104-7092
`Phone (206) 622-4900
`Fax (206) 682-6031
`
`655101
`“8/5
`
`Express Mail Certificate No:
`Docket No:
`Date:
`
`R3871013523US
`120079.401
`December 1, 1995
`
`Transmitted herewith for filing is the patent application of:
`
`Inventor:
`For:
`
`~
`
`Geoffrey J. Bunza
`SYSTEM AND METHOD FOR SIMULATION OF COMPUTER
`SYSTEMS COMBINING HARDWARE AND SOFTWARE
`INTERACTION
`Enclosed are:
`
`[ X]
`[
`]
`[
`]
`[
`]
`[
`]
`[
`]
`[
`]
`[ X]
`
`ll sheets of drawings
`, a corporation of .
`An assignment ofthe invention to:
`A Declaration and Power of Attorney (facsimile).
`An associate power of attorney.
`A verified statement to establish small entity status under 37 CPR. 1‘9 and 37 C.F.R. 1.27 (facsimile)
`A certified copy of Application No. , filed , fi'om which priority is claimed, .
`The filing fee has been calculated as shown below.
`Filed without fee or formal papers,
`
`ther Than A
`mail Enti
`
`ASSIGNMENT
`
`Total Claims
`
`lnde - endent Claims
`( ) Multiple Dependent
`Claim Presented
`
`but...“—
`
`Please charge my Deposit Account No. 19-1090 in the amount of $_. A duplicate copy of this sheet is enclosed,
`A check in the amount of$__ is enclosed.
`The Assistant Commissioner is hereby authorized to charge payment of the following fees associated with this
`communication or credit any overpayment to Deposit Account No. l9-1090. A duplicate copy of this sheet is enclosed
`[ ] Any additional filing fees required under 37 CFR. 1‘ 16‘
`[ ] Any patent application processing fees under 37 C.F.R. l. 17‘
`
`Respectfully submitted,
`SEED and BERRY
`
` Michael J.
`
`warm/1743
`
`Registration No. 35,859
`
`5
`5
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`
`
`[18/568401
`
`PATENT
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`Applicant
`Filed
`
`For
`
`:
`:
`
`:
`
`Geoffrey J 1 Bunza
`December 1, 1995
`
`SYSTEM AND METHOD FOR SIMULATION OF
`COMPUTER SYSTEMS COMBINING HARDWARE
`AND SOFTWARE INTERACTION
`
`Docket No.
`
`Date
`
`1
`
`:
`
`120079.401
`
`December 1, 1995
`
`Box Patent Application
`Assistant Commissioner for Patents
`
`Washington, DC 20231
`
`
`CERTIFICATE OF MAILING BY "EXPRESS MAIL"
`
`Sir:
`
`I hereby certify that the enclosures listed below are being deposited with the
`United States Postal Service "EXPRESS MAIL Post Office to Addressee" service under 37
`
`C.F.R. § 1.10, Mailing Label Certificate No, RB871013528US, on December 1, 1995,
`addressed to: Box Patent Application, Assistant Commissioner for Patents, Washington, DC
`2023 1 ,
`
`Respectfully submitted,
`SEED and BERRY
`
`Kay HZwe
`
`Enclosures:
`Postcard
`Form PTO-1082 (+ copy)
`Specification, claims, abstract
`Drawings (Figures 1-10)
`kthJD/2746
`
`6
`6
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`
`
`EXl
`
`MAILN0.: WWW («J/Q]
`{ll/586401
`
`Description
`
` Y M AND METHOD F R SIMULATION OF COMPUTER SYSTEMS
`COMBINING HARDWARE AND SOFTWARE INTERACTION
`
`5
`
`'
`
`Technical Field
`
`10
`
`15
`
`20
`
`The present
`
`invention relates generally to computer hardware
`
`simulators, and, more specifically, to a system and method for the simulation of
`
`systems that combine hardware and software interaction.
`
`Background of the Invention
`
`The use of computer simulation has become widespread in many
`areas such as circuit design. The cost of manufacturing an integrated circuit is
`
`extremely high, and it
`is desirable that
`the hardware incorporated into the
`integrated circuit be tested prior to the actual fabrication of the chip. To that end,
`integrated circuit manufacturers often use simulators to test the hardware and the
`
`software intended to be executed by the hardware. The desired hardware design
`is designated as the target hardware, while the software intended to be executed
`
`by the target hardware is designated as the target program.
`
`There are several techniques that are used to simulate the target
`
`hardware and software. One approach is to simulate the hardware using a
`
`computer hardware simulator. The hardware simulator is a software program
`
`that simulates the responses of the target hardware and is implemented entirely in
`
`software.
`
`Thus,
`
`in the hardware simulator,
`
`the target hardware and target
`
`25
`
`program are simulated entirely by computer software. Another approach uses a
`
`microprocessor emulator to model a microprocessor that is typically part of the
`
`target hardware and used to execute the target program. Thus, the target program
`
`and portions of the target hardware are simulated by hardware devices such as
`
`the processor emulator.
`
`30
`
`Each of the above-described approaches has advantages and
`
`disadvantages. The hardware simulator is extremely slow and cumbersome,
`
`particularly when used to simulate a complex microprocessor executing a target
`
`program. Thus, testing a complete target program is impractical due to the
`
`extremely long execution times required by the typical hardware simulator. The
`
`35
`
`processor emulator is able to execute a target program much faster than the
`
`hardware simulator but requires the development of external circuitry that is
`
`__)
`
`Kg
`
`7
`7
`
`,
`
`TZOPQTZT 1009
`SYNOPSYS 1009
`
`

`

`expected to interact with the target microprocessor.
`
`Therefore,
`
`it can be
`
`appreciated that there is a significant need for a system that allows complete
`testing of the target hardware and software with efficiency and low cost. The
`
`present invention provides this and other advantages, as will be illustrated by the
`following description and accompanying figures.
`
`Summgy of the Invention
`
`The present invention is embodied in a system and method for
`
`testing and analyzing electronic systems, including a target microprocessor and
`
`simulated target circuitry, and accompanying target software to be executed on
`
`the target microprocessor. The system comprises a memory storing a plurality of
`
`computer instructions, including the target software and a processor emulator
`employing a hardware device for emulating the microprocessor. The processor
`
`emulator is coupled to the memory to execute the computer instructions. A
`
`hardware simulator is coupled to the processor emulator to simulate the target
`
`circuitry. A communications interface controls communication between the
`
`memory, the processor emulator, and the hardware simulator. The processor
`
`emulator communicates with the memory to receive the computer instructions
`
`and communicates with the hardware simulator using the communications
`
`interface only on an occasion when the target software requires interaction with
`
`the target circuitry,
`
`The processor emulator may be coupled to the hardware simulator
`
`by computer network connection, with the communications interface controlling
`
`communications over the network. The system may also include an exception
`
`detector coupled to the processor emulator to detect the occasion requiring the
`
`target software to interact with the target circuitry. The exception detector may
`
`temporarily halt execution of the plurality of computer instructions while the
`
`hardware simulator processes the occasion requiring the target software to
`
`interact with the target circuitry. The occasion requiring the target software to
`interact with the target circuitry may be an input/output (I/O) instruction to the
`hardware
`simulator, with
`the
`communication
`interface
`controlling
`
`communication of the I/O instruction from the processor emulator to the
`hardware simulator.
`
`The processor emulator typically utilizes a first data format, and
`
`the hardware simulator uses a second data format. The system includes a
`translator to convert an event requiring the target software to interact with the
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`8
`8
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`target circuitry from the first data format to the second data format for events
`requiring interaction. The hardware simulator may contain a processor model
`shell to simulate the target circuitry.
`In such circumstances, the system also
`includes a mapper to map the event type to a set of signal sequences compatible
`with the processor model shell. The processor emulator may be coupled to the
`translator and mapper by a first computer network connection, with the
`communications interface controlling communication over the first network
`connection. The translator and the mapper may be coupled to the hardware
`simulator by a second computer network connection, with the communications
`interface controlling communication between the processor emulator and the
`hardware simulator over the first and second network connections. In a preferred
`embodiment, the mapper may directly determine the event type and map the
`event type into a set of signals compatible with the hardware simulator without
`the need of a translator.
`In one embodiment the processor emulator is a microprocessor
`emulator with the memory integrated therein with the integrated memory
`containing the computer instructions. In an alternative embodiment the processor
`emulator is a hardware circuit emulator with memory integrated therein, with the
`integrated memory containing the computer instructions.
`In another alternative embodiment,
`the system includes first and
`second target microprocessors each having a memory storing a set of computer
`instructions to be executed on the respective target microprocessors.
`In this
`embodiment,
`the communications interface controls communication from the
`first and second processor emulators to the hardware simulator. The first and
`second processor emulators communicate with the first and second memories,
`respectively,
`to receive the first and second sets of computer instructions
`therefrom.
`The first processor emulator communicates with the hardWare
`simulator using the communications interface only on an occasion when the
`target software for the first target microprocessor requires interaction with the
`target circuin and the second processor emulator communicates with the
`hardware simulator using the communications interface only on an occasion
`when the target
`software for
`the second target microprocessor
`requires
`interaction with the target circuitry.
`The dual target processor embodiment may also include first and
`second portions for the communications controller, with the first communications
`controller portion being operatively coupled to the first processor emulator to
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`9
`9
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`control communication between the first processor emulator and the hardware
`simulator only on the occasions when the target software for the first target
`microprocessor requires interaction with the target circuitry.
`The second
`communications controller portion is operatively coupled to the second processor
`emulator to control communications between the second processor emulator and
`the hardware simulator only on occasions when the target sofiware for the
`second target microprocessor requires interaction with the target circuitry. In this
`embodiment, the first and second processor emulators may be microprocessor
`emulators or hardware circuit emulators.
`
`Brief Description of the Drawings
`Figure 1 is a fimctional block diagram of a traditional hardware
`simulator employing a processor functional model to simulate target program
`execution.
`
`set simulator.
`
`Figure 2 is a functional block diagram of a conventional instruction
`_
`Figure 3 is a functional block diagram of a traditional hardware
`simulator employing a hardware modeler to simulate target program execution.
`Figure 4 is a functional block diagram of a conventional processor
`
`10
`
`15
`
`20
`
`emulator.
`
`Figure 5 is a functional block diagram of a conventional hardware
`circuit emulator.
`Figure 6 is a fimctional block diagram ofthe present invention.
`Figure 7 is a table of processor operations which are used as part of
`a communications protocol with the system of Figure 6.
`Figures 8A and BB are flowcharts illustrating the operation of the
`control program in the present invention.
`Figure 9 is a functional block diagram of a dual processor
`configuration of the present invention employing two processor emulators.
`Figure 10 is a block diagram of a dual processor configuration of
`the present invention employing a processor emulator and a software processor
`simulation engine.
`
`Detailed Description of the Invention
`With the advent of 32-bit microprocessors and complex operating
`software, embedded systems have become very complex systems. The vast
`
`10
`10
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`25
`
`30
`
`35
`
`//
`tho
`i
`u
`
`

`

`
`
`majority of electronic products built today include some form of computer
`
`hardware executing a stored sofiware program. An embedded system may
`
`typically include a microprocessor executing instructions and interacting with an
`
`application specific integrated circuit (ASIC) or a custom Integrated Circuit (IC).
`The microprocessor used in the system is designated herein as a target
`
`target
`interacts with the
`circuitry that
`external
`The
`microprocessor.
`microprocessor, whether it
`is the ASIC, custom 1C, or some other form of
`
`electronic circuitry, is designated herein as the target circuitry. The combination
`
`of the target circuitry and the target microprocessor is designated herein as the
`
`target hardware. The software program that is intended to be executed by the
`
`target microprocessor is designated herein as the target program.
`Given the complexity and density of modern electronics designs, it
`
`is desirable that the first system prototype, including the target hardware and the
`
`target program, is typically close in form, fit, and function to the end product.
`The target hardware prototypes would therefore include the ASIC and custom IC
`designs, which were fabricated and passed their respective qualification and
`acceptance tests at the foundry.
`With respect to the target program, code is typically designed,
`
`written, and tested, module by module. The module integration process also
`involves testing of the integrated software modules. However, because the target
`hardware may not be available at the time of the software development, it is not
`possible to test the interaction of the target hardware and the target program. To
`substitute for the missing target hardware, pieces of the design are “stubbed out,”
`or mockups built
`to substitute for anticipated missing parts of the target
`hardware. The term “stubbed out” refers to a mock response to a program call to
`
`a location in the yet unbuilt circuitry. The programmer must program a return
`command that causes the target program to ignore the lack of a true response
`fiom the target circuitry. The substitution of mocked up target hardware requires
`further interpretation of the original hardware design specifications.
`It
`is
`common to find that no single combined soflware system integration occurs
`before the software is loaded onto the hardware prototype, let alone tested as a
`
`whole (stubbed out or otherwise).
`When software engineers start work, the physical target hardware
`which will ultimately execute the target program does not exist. The target
`program can be cross-compiled onto an existing system for testing, and the
`hardware-dependent parts of the target program can be emulated with other
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`11
`11
`
`7
`
`TZOPQTZT 1009
`SYNOPSYS 1009
`
`

`

`
`
`software modules. Typically, this entails writing simulated hardware functions
`to simulate the low—level interaction with the target hardware, allowing a “black-
`box” approach to the design. Thus, a particular software function can be written
`to simulate a response expected from the target hardware. If the projected target
`hardware changes, then only the particular simulated hardware function need be
`modified.
`The rest of the simulation program remains unchanged.
`This
`approach also allows some conceptual testing to occur. However, the ability to
`emulate the target hardware in custom software modules is normally very
`limited.
`It can be a lengthy modeling task to write an equivalent functional
`module of the unbuilt target hardware.
`It can be an even larger task to verify that
`the sofiware module provides compatible responses to the target hardware circuit
`because the software module is simply the programmer’s interpretation of the
`original system specifications. The target program is not normally used with this
`approach, unless the development system happens to be the expected target
`computer system to some large extent.
`
`the hardware and software components of a target
`Typically,
`system design are brought together for the first time when the prototype target
`hardware has been fabricated. Because of the prior unavailability of the actual
`target hardware, one often finds that the target program loaded at the time of the
`integration of the prototype target hardware and software does not work.
`It is
`
`the integration problems are strictly due to software
`common to find that
`This may cause a significant delay in the software
`complications alone.
`development due to the problems in the target program. Other problems with the
`integration may be caused by the interaction of the target hardware with the
`
`target program. Consequently, considering the large cost of ASIC and custom IC
`design, and the relatively low cost ease of software modification, it is common
`
`that the software will be force-fitted to the target hardware prototype, thereby
`increasing the overall planned software development time.
`
`The target hardware can be simulated at the chip, board, and
`
`system level to varying extents. Because of the availability of simulated target
`hardware,
`there is a significant benefit to including the target program in a
`
`system simulation, including the chance to debug code and verify the correct
`
`operation of both the target program and target hardware before the target
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`hardware is built. Problems associated with the interaction between the target
`hardware and the target program Can be detected and corrected before final
`
`12
`12
`
`.
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`hardware fabrication, often saving costly and time-consuming redesign of the
`ASIC.
`
`Current technology facilitates only primitive and low performance
`hardware and software simulation. Large amounts of processing power are
`required to simulate a microprocessor executing a few hundred lines of the target
`program code.
`Traditional hardware simulated microprocessors
`execute
`approximately 1-4 microprocessor instructions per second, which barely allows
`for a system to boot itself up. Meaningful system simulations, where significant
`amounts of target program code are to be executed, require massive computing
`resources.
`
`The target hardware prototype is built in order to verify that the
`target program runs with the custom designed target circuitry and target
`microprocessor. One issue in using the target hardware prototype is the loss of
`debug visibility once the prototype is built. As those skilled in the art can readily
`appreciate,
`the typical embedded system does not have any debugging and
`control capabilities. When errors are detected in the prototype target system,
`there are no facilities to utilize the software development tools required to debug,
`analyze and correct the problems. A loss of visibility refers to the inability to
`examine the contents of internal registers, memory locations, and the like. The
`prototype hardware also lacks debugging control ability, which is the ability to
`control the flow of the target program using start and stop command, single step
`commands, and the like.
`
`A brief discussion of conventional simulation systems will serve to
`distinguish the present
`invention. Conventional simulations systems can be
`categorized as hardware,
`software, or a combination.
`The “brute-force”
`
`illustrated in
`hardware simulation method of verifying the target system,
`Figure 1, uses a hardware simulator 20. The hardware simulator 20 is a software
`
`program that accepts a description of the target hardware, including electrical and
`logical properties of the target microprocessor and the target circuitry. The target
`hardware design may be specified graphically by schematic diagrams or by a
`hardware description language (HDL),
`such as VHDL.
`The hardware
`
`simulator 20 is a commercially available product.
`
`The hardware simulator 20 simulates signal propagation and logical
`
`functionality of the target hardware event by event.
`
`It should be noted that a
`
`typical microprocessor instruction cycle is actually the result of a large number
`of hardware events within the target. Thus, the hardware simulator 20 attempts
`
`10
`
`15
`
`20
`
`25
`
`3O
`
`35
`
`l3
`13
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`8
`
`to represent signal timing, signal strength, and logical function as accurately as
`possible, often enabling sub-nanosecond timing accuracy in simulating these
`hardware events. To achieve this degree of accuracy for a highly complex target
`microprocessor, functions are often represented with detailed structures, although
`most hardware simulators allow multiple levels of modeling abstraction from a
`switch or transistor level model to a high level behavioral model.
`A target program 22 is compiled into object code, and the object
`code is downloaded into a processor memory model 24 within the hardware
`simulator 20. A processor functional model 26 is a software description,
`including the electrical and logical properties, of the target microprocessor, while
`a target circuitry functional mode128 provides a model of the target circuitry,
`such as an ASIC, or other custom or semi-custom design.
`The hardware
`simulator 20 allows the processor functional model 26 to simulate execution of
`the target program 22 event by event. As discussed above,
`the processor
`frmctional model 26 and the target circuitry functional model 28 can be specified
`to various levels of abstraction by a conventional HDL.
`There are disadvantages in using the hardware simulator 20 to
`simulate the target hardware. Microprocessor manufacturers are cautious about
`providing the full-functional processor model 26 that could be
`reverse-
`engineered into a competitive product.
`In addition, the full-frmctional processor
`model 26 can be extremely detailed for a complex circuit such as the target
`microprocessor. For an accurate simulation,
`the hardware simulator 21 must
`simulate all activity that occurs in the target microprocessor using the processor
`functional model 26 to detect tinting errors, race conditions, and the like. This
`requires many processor cycles in the hardware simulator 20 to simulate each
`instruction of the target program 22 by the target hardware. The execution time
`required to simulate the full-functional processor model 26 can add significantly
`to the simulation run-times. The target program 22 can be quite long. The
`additional burden of trying to run longer simulation required for larger target
`program 22 into the processor memory model 24 can consume large amounts of
`system resources, and simulation run time can become unacceptably long.
`Typical simulation speeds may only reach 2-4 microprocessor instructions per
`second.
`
`If the target program 22 malfunctions, then the programmer has the
`unenviable task of debugging the target program and relating the object code
`locations back to some high-level program statements outside the typical
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`14
`14
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`software development environment.
`
`This debugging task must
`
`typically be
`
`accomplished without the aid of debuggers or any other software design and
`
`analysis tools.
`Variations on the use of the full
`
`fimctional mode126 in the
`
`hardware simulator 20 include a trade~off in both timing accuracy and gross
`
`fimctionality. To speed the overall hardware simulation,
`
`timing accuracy is
`
`sometimes only maintained for major processor or bus cycles, reducing the
`
`overall number of simulated events. However, the loss of such detailed analysis
`
`means that timing problems and race conditions may not be reliably detected.
`
`Delay calculations can also be curtailed using “zero-delay” timing for hardware
`functions. A zero-delay timing system assumes that all events happen without
`
`propagation delays or response delays. This assumes that all internal functions in
`
`the target microprocessor occur with zero delay and that response from that
`
`target circuitry also occur with zero delay. While this approach speeds up the
`simulation, it does not providei an accurate simulation of the system timing.
`Another form of software simulation of the target hardware uses an
`
`instruction set simulator (ISS) 40, illustrated in Figure 2. The ISS 40 includes a
`
`memory 42 that contains the target program 22. The ISS 40 strives to guarantee
`functional accuracy of both instruction functions and memory references only at
`the processor instruction level. As a result, accuracy to detailed internal timing is
`sacrificed for speed. The speed of a typical ISS 40 is on the order of 1,000-
`10,000 microprocessor instructions per second. While the ISS 40 provide a
`functional model of the target microprocessor, they do not interface with custom
`designed hardware such as
`the ASIC.
`The ISS 40 executes the target
`program 44, but has only limited visibility to circuitry outside of the target
`microprocessor.
`The typical ISS 40 does not represent any custom target
`circuitry in simulation beyond a register reference, and hence is of limited value
`to hardware designers.
`
`The systems illustrated in Figures] and 2 simulate the target
`hardware completely in software. As is known by those of ordinary skill in the
`art, software simulation of the target hardware offers relatively low cost and
`flexibility'in altering the simulated target hardware. However, the total software
`simulation approach suffers from the disadvantages that the target hardware often
`cannot be completely modeled.
`In addition, the simulator processing time is
`enormous for the processor functional model 26 (see Figure 1) making it difficult
`or impossible to simulate the complete target program 22.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`15
`15
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`10
`
`A common technique to address
`e unacceptably long run-times
`encountered with the full functional mode122’(sLee Figure 1)15 to replace the full
`fimctional model1n the hardware simulator 20 with a physical integrated circuit
`(IC) microprocessor 50, as illustrated in Figure 3. The micr0processor 50 is
`connected to the hardware simulator 20 viaLa/hardware modeler 52 The target
`program 22 is contained'm the memory mode 4 in the hardware simulator 20,
`and all instructions are executed out of the memory modc124, as previously
`
`discussed with respect to Figure 1. A significant difference between the system
`
`illustrated in Figure] and that of Figure 3 is that the processor functional
`
`model 26 (see Figure 1), which is simulated completely in software, is replaced
`
`by the physical microprocessor 50 and the hardware modeler 52.
`
`The
`
`microprocessor 50 may be the actual target microprocessor or other circuit to
`
`simulate the behavior of the target microprocessor.
`
`It should be noted that the
`
`physical microprocessor 50 and the hardware modeler 52
`
`are hardware
`
`components rather than software simulations. The cost of the typical hardware
`modeler 52 can be quite high, ranging from $40,000 to over $200,000.
`While the use of the hardware modeler 52 can provide a full
`
`functional processor model, regardless of processor complexity, the significant
`extra cost of the hardware modeler 52 is not always reflected by an increase in
`
`a vector
`contains
`hardware modeler 52
`simulation performance. The
`memory (not shown) to store the input data for each pin of the physical
`microprocessor 50 for each time slice of the hardware simulator. A time slice
`can be arbitrarily small, and is typically less than a single microprocessor clock
`cycle. As previously discussed, the detection of timing problems requires an
`event by event analysis, including propagation delays, of the target hardware.
`The hardware modeler 52 runs lockstep with the hardware simulator 20 with the
`physical microprocessor 50 generating the next set of binary signals from the
`vector memory at the microprocessor pin connections for incorporation with the
`next simulated step of the hardware simulator 20.
`Thus,
`the hardware
`modeler 52
`operates
`in
`complete
`synchronization with
`the
`hardware
`simulator 20.
`
`The processor in the hardware modeler 52 is ofien a dynamic
`device that must maintain a running clock in order to retain data. Because the
`
`hardware simulator 20 simulates the system responses event by event for an
`arbitrarily small time slice, the physical microprocessor 50 must wait for each
`simulation cycle to be completed by the hardware simulator 20. Therefore, the
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`16
`16
`
`SYNOPSYS 1009
`TZOPQTZT 1009
`
`

`

`ll
`
`ojt
`physical microprocessor 50 must be reset areal-fire start of each simulation cycle,
`and all the previous vectors rerun. As the simulations get longer, the time taken
`
`to rerun all the previous vectors increases. Executing the target program 22 takes
`
`a large number of clock cycles, often exceeding the maximum amount of vector
`
`memory available for the hardware modeler 52 and thus severely limiting the
`length of the target program.
`In addition to the large memory refluirement in the
`hardware modeler 52, the execution of the target program-24'AF“ the object-code
`level does not provide a convenient means for debugging the target program 22.
`
`The system illustrated in Figure 3 uses some hardware, namely the
`
`hardware modeler 52, to model portions of the target hardware. However, as
`
`discussed above, this approach is both costly and limited in its ability to model
`
`the large size of the typical target program 22. Another device used to model the
`
`target processor is a processor emulator 60, illustrated in Figure 4. The processor
`
`emulator 60 is a hardware device that substitutes for the target microprocessor.
`
`Processor emulators are conventional devices presently available fr