Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20020059054
Kind Code
A1
Bade, Stephen L. ; et al.
May 16, 2002
Method and system for virtual prototyping
Abstract
An integrated design environment (IDE) is disclosed for forming virtual embedded systems. The IDE includes a design language for forming finite state machine models of hardware components that are coupled to simulators of processor cores, preferably instruction set accurate simulators. A software debugger interface permits a software application to be loaded and executed on the virtual embedded system. A virtual test bench may be coupled to the simulation to serve as a human-machine interface. In one embodiment, the IDE is provided as a web-based service for the evaluation, development and procurement phases of an embedded system project. IP components, such as processor cores, may be evaluated using a virtual embedded system. In one embodiment, a virtual embedded system is used as an executable specification for the procurement of a good or service related to an embedded system.
Inventors:
Bade; Stephen L.
(Lindon, UT)
, Ben-Chorin; Shay
(Cupertino, CA
)
, Caamano; Paul
(San Mateo, CA
)
, Montoreano; Marcelo E.
(Santa Cruz, CA
)
, Taggu; Ani
(Campbell, CA
)
, Thoen; Filip C.
(San Jose, CA
)
, Wills; Dean C.
(Corvallis, OR
)
Correspondence Name and Address:
TWO PALO ALTO SQUARE
FENWICK & WEST LLP
PALO ALTO
CA
94306
US
Series Code:
872435
Filed:
June 1, 2001
U.S. Current Class:
703/20
U.S. Class at Publication:
703/20
Intern'l Class:
G06F 009/455
Claims
What is claimed is:
1. A computer system for simulating the operation of an embedded system using a software application residing in the memory of a computer, comprising: a design application configured to form a hardware specification of an embedded system, the design application including: a design language having at least one graphical symbol adapted to form a finite state machine (FSM) representation of electronic hardware, each graphical symbol of the design language having a graphical portion and a user-definable textual portion defining the behavior of the graphical symbol, a library including at least one instruction set accurate simulator for simulating the behavior of a target processor core having at least one memory read pin, at least one write memory pin, and at least one interrupt pin, a graphical user interface adapted to permit a user to select an instruction set accurate simulator of a target processor core and to form a FSM representation of a hardware component in the design language, and a configuration interface for coupling memory read/write signals and interrupt signals of the instruction set accurate simulator to corresponding signals of a the hardware component; a test bench builder for generating a graphical representation of at least one interactive test bench and for selecting signals or variables to be coupled to a graphical representation of a user interface for each interactive test bench; a software debugger including a debugging interface for associating a breakpoint of execution a graphical symbol of the finite state machine representation of the hardware component; a graphical database and a behavioral database coupling data associated with the hardware description to a code generator; a compiler for compiling the output of the code generator into an object file of the hardware description; a discrete event simulation engine configured to execute the object file of the hardware description; a first API interface adapted to couple the discrete event simulation engine to each of the interactive test benches; at least one API interface adapted to couple the discrete event simulation engine to the instruction set accurate simulator of the hardware description; and at least one API interface adapted to couple the instruction set accurate simulator to a software debugger, the software debugger configured to load at least one binary program code compiled for the target processor.
2. The computer system of claim 1, wherein the debugging interface is configured to permit the at least one compiled binary program code to be stepped to the break points of execution.
3. The computer system of claim 1, wherein the design language is an adaptation of the specification and description language (SDL).
4. The computer system of claim 1, wherein the computer system has a simulation speed selected so that the software application executes at a rate greater than one million instructions per second.
5. The computer system of claim 1, wherein the computer system serves as a hardware emulator and has a simulation speed sufficient to boot an embedded system operating system is less than one minute.
6. The computer system of claim 1, wherein the computer system is coupled to a server of a computer network.
7. The computer system of claim 6, wherein the computer network is selected from the group consisting of: a wide area network, a local area network, an Intranet, an extranet, or a computer network coupled to the Internet.
8. The computer system of claim 6, wherein a client computer may be coupled to the computer system by a network connection.
9. The computer system of claim 6, further comprising: a design repository coupled to the server adapted to store a design specification for each of a plurality of embedded systems, each design specification including sufficient information to generate the hardware specification for the embedded system.
10. The computer system of claim 9, further comprising a matching engine coupled to the design repository for associating metadata with each design specification and matching vendors to the stored design specifications based on the metadata.
11. The computer system of claim 9, wherein each design specification includes at least one design specification source file configured to permit the hardware specification to be viewed in the design language and at least one executable file to run a simulation of the embedded system that includes at least one of the interactive test benches.
12. The computer system of claim 9, wherein each design specification includes at least one dynamic link library (DLL) that may be loaded by a loader executable to permit the design specification to be viewed in the design language and to run a simulation of the embedded system that includes at least one of the interactive test benches.
13. The computer system of claim 9, further comprising: a design manager configured to control access to the design specifications stored in the design repository.
14. The computer system of claim 6, wherein each design specification includes a design specification source file to describe each hardware element system, a file for each instruction set simulator of the embedded system, and a dynamic link library to execute the design specification.
15. The computer system of claim 9, wherein the server is coupled to the client computer via the Internet.
16. The computer system of claim 15, further comprising: an on-line bulletin board coupled to the server for a user to post a design specification.
17. The computer system of claim 16, wherein the bulletin board is a bidding board.
18. The computer system of claim 9, further comprising: content and a content viewer configured to interactively explain to a user at least one attribute of a selected embedded system.
19. The computer system of claim 1, further comprising: a walkthrough application including content and a content viewer configured to interactively explain to a user at least one attribute of an executable file of the hardware description of a selected embedded system.
20. The computer system of claims 18 or 19, wherein the walkthrough application is configured to allow the user to control the operation of a simulation of the embedded system through the content viewer.
21. The computer system of claim 20, wherein the embedded system includes a processor core and at least one reference hardware peripheral for evaluating the processor core.
22. A computer-implemented method for assisting a user to evaluate at least one component of an embedded system, the method comprising: forming a virtual embedded system including an instruction set accurate simulator of a target processor core coupling read, write, and interrupt signals with a finite state machine (FSM) simulation of at least one hardware element; coupling a virtual test bench emulating a human/machine interface to the virtual embedded system, the virtual test bench having a graphical user interface adapted to interact with the virtual embedded system; receiving from the user a binary program code of a software application compiled for the target processor core; and responsive to a request from a user, loading the software application and running a simulation of the embedded system.
23. The method of claim 22, further comprising: creating content for explaining the operation of the virtual embedded system; and responsive to a user request, providing the content as an interactive demonstration.
24. The method of claim 22, wherein the virtual embedded system resides on a server and the method further comprises: forming a data connection between the server and a client computer; receiving command and data user inputs from a web browser residing on the client computer; and providing graphical display data of the simulation running on the server to the web browser residing on the client computer.
25. The method of claim 24, wherein the server is a network server coupled to the client computer via the Internet and the method further comprises: monitoring the user's interaction with the virtual embedded system; and recording data associated with an interaction of the user with the virtual embedded system.
26. The method of claim 24, further comprising: forming a plurality of virtual embedded systems in a library; receiving a request from a user for a selected virtual embedded system; and recording data associated with usage of the selected virtual embedded system.
27. The method of claim 26, further comprising: requesting the user to submit registration data.
28. The method of claim 25, further comprising: providing each user with a graphical user interface to modify the virtual embedded system; monitoring modifications made by a plurality of users to the virtual embedded system; and determining a statistically popular modifications to the virtual embedded system.
29. The method of claim 24, wherein the software debugger is adapted to load binary program code compiled for a target processor core and the method further comprises: responsive to a user request, loading onto the virtual embedded system a binary executable program file of a software application compiled for the processor core; and displaying a simulation of the virtual embedded system executing the software application.
30. The method of claim 22, further comprising: providing the user a graphical interface having a design language including a plurality of graphical symbols adapted to form a finite state representation of a user-defined hardware element that may be coupled to the virtual embedded system.
31. The method of claim 30, wherein the graphical symbols have a graphical portion and a textual portion with at least one of the graphical symbols including a textual portion adapted for the user to describe a behavior of the symbol.
32. The method of claim 31, wherein a user may input a text portion including at least one command written in the ANSI C/C++ language.
33. The method of claim 31, wherein the design language is an adaptation of a specification and description language (SDL).
34. The method of claim 22, wherein a plurality of virtual embedded systems are stored in a database, the method further comprising: responsive to a user request, selecting one of the virtual embedded systems for evaluation.
35. The method of claim 22 further comprising: forming content for the embedded system, the content including a at least one graphical control interface configured to interact with the simulation of the embedded system: responsive to a user request displaying content associated with the embedded system; and responsive to a user input to the graphical control interface, displaying an interaction with the simulation.
36. The method of claim 35, wherein the content is a tutorial of the embedded system.
37. In a computer system having a graphical interface and a design language for forming a finite state machine (FSM) representation of a hardware partition of an embedded system, a method of designing an embedded system, the method comprising: forming a library of processors including an instruction set accurate simulator for each of the processor cores in the library; responsive to a first sequence of user commands, selecting at least one of the processor cores from the library as a target processor; responsive to a second sequence of user commands, forming a virtual embedded system including an instruction set accurate simulator of a target processor core coupling read, write, and interrupt signals with a finite state machine (FSM) simulation of at least one hardware element; responsive to a request from the user, loading an executable binary file of a software application compiled for the target processor; executing a simulation of the virtual embedded system running the software application; responsive to a user request, displaying a graphical representation of the execution of the software on the virtual embedded system that includes a software debugger interface to debug the loaded software and a virtual test-bench having a graphical user interface adapted to interact with the simulation.
38. The method of claim 37, wherein the design language includes a plurality of graphical symbols with each graphical symbol having a graphical semantic portion and a textual semantic portion.
39. The method of claim 38, wherein the design language includes: a start object defining a starting point of the finite state machine at an initialization time, the start object having an output connector activated when the start object is initialized; a task object including a field for inputting computer code in the C language for defining a behavior of the task object and a connector port for coupling the task object to other objects; a state object for representing a state of the finite state machine; a decision object having an evaluation field for directing a flow of execution based on a result of an expression in the decision field; a signal-out object for sending a communication signal; a signal-in object for receiving a communication signal; a connector object for connecting control flow; a symbol object having at least one user-definable pin connector and containing a block or process object: a block object for describing the behavior of one or more processes; and a process object for representing a finite state machine process.
40. The method of claim 37, further comprising: storing the virtual embedded system as a design in a design repository coupled to a server; and providing access privileges to the design to a selected individual or group.
41. The method of claim 40, further comprising: responsive to a user command, providing access privileges to the design to a group of vendors.
42. The method of claim 41, wherein the design is accessible from an on-line bidding board.
43. The method of claim 41, wherein access privilege to the design are provided to a group of vendors selected by the user.
44. The method of claim 40, wherein the design is accessible by an embedded system design team.
45. The method of claim 40, further comprising a design manager application, the method further comprising: permitting one or more members of a design team to select edit privileges of at least one version of the design.
46. The method of claim 45, further comprising: permitting one or more members of the design team to load and execute a binary program executable of a software application compiled for the target processor core onto the design.
47. The method of claim 45, further comprising: providing version control and regulating editing access to maintain a consistent version of the design.
48. The method of claim 37, further comprising: storing a plurality of virtual embedded systems in a library; and responsive to a user request, providing the user a copy of one of the virtual embedded systems stored in the library.
49. The method of claim 38, further comprising the graphical user interface is configured to permit a a user to associate a breakpoint of execution with a graphical symbol, the method further comprising: responsive to a user input, associating a breakpoint of execution with a graphical symbol; receiving a request to debug software; and stopping the simulation responsive to a command flow of the FSM representation of the hardware element reaching the graphical symbol of the breakpoint of execution.
50. The method of claim 49, further comprising: responsive to a user request, single-stepping the simulation to sequential breakpoints of execution in the command flow of the FSM representation of hardware elements.
51. The method of claim 49, further comprising: responsive to a user request, single-stepping the simulation by a preselected number of time units.
52. A computer implemented method of embedded system design, the method comprising: selecting an instruction set accurate simulator of a target processor core; generating a virtual hardware component that is a finite state representation of at least one hardware component;, linking read, write, and interrupt signals of the instruction set accurate simulator of the target processor core with corresponding signals of the at least one virtual hardware component to form a virtual embedded system; coupling a virtual test bench to at least one signal or variable of the virtual embedded system to simulate a human/machine interface; and coupling a software debugger to the virtual embedded system that is configured to load and run on the virtual embedded system at least one binary program executable of a software application compiled for the target processor core.
53. The method of claim 52, further comprising: selecting the target processor core from a library having a plurality of instruction set accurate simulators for a plurality of processor cores.
54. The method of claim 52, further comprising: selecting the virtual hardware component from a library of virtual hardware components.
55. The method of claim 54, further comprising: modifying the virtual hardware component.
56. The method of claim 52, further comprising: loading benchmark software in an evaluation phase of an embedded system project and running a simulation of the virtual embedded system executing the benchmark software.
57. The method of claim 52, further comprising: loading binary program executables of development software compiled for the target processor core in a development phase of an embedded systems project and running a simulation of the virtual embedded system executing the development software.
58. The method of claim 57, further comprising: debugging the development software using a software debugger.
59. The method of claim 52, farther comprising: storing the virtual embedded system as a design having at least one executable file in a design repository.
60. The method of claim 59, wherein th e design is stored on a server accessible to a user-group.
61. The method of claim 60, wherein the user-group is a geographically distributed embedded system project team.
62. The method of claim 59, further comprising: providing a version of a vendor offering a good or service related to the virtual embedded system.
63. The method of claim 62, wherein the design is stored on a server and a vendor is provided access to the design via network connection.
64. A method of designing an embedded system, the method comprising: defining a system architecture of the embedded system; designing a virtual prototype of the embedded system having an instruction set accurate simulator of a target processor core coupling read, write, and interrupt signals with a finite machine (FSM) representation of at least one hardware element; coupling the virtual prototype to a software debugger having a debugging interface and a virtual test bench having a graphical representation of a human/machine interface for interacting with the embedded system; developing at least one software application for the processor core; loading compiled binary program code of the at least one software application for execution of the virtual prototype; and initiating a simulation of the virtual prototype executing the at least one software application.
65. The method of claim 64, further comprising: developing a hardware implementation using the virtual prototype as a functional specification describing a hardware partition.
66. The method of claim 65, further comprising: evaluating the operation of the embedded system executing the at least one software application; and responsive to a result of the evaluation, modifying a hardware or software component of the embedded system.
67. The method of claim 64, wherein the step of defining the system architecture comprises: selecting at least one embedded system component for evaluation; forming a virtual evaluation platform including the selected embedded system component; loading a benchmark software application for execution on the virtual evaluation platoform; and evaluating performance of the virtual evaluation platform executing the benchmark software application.
68. A method of providing information to potential suppliers for procuring a good or service associated with an embedded system, the method comprising: defining a system architecture of the embedded system; designing a virtual prototype of the embedded system having an instruction set accurate simulator of a target processor core and a virtual hardware element that is a finite state machine (FSM) representation of a hardware element configured to couple memory read/write requests and interrupt signals with the instruction set accurate simulator of the target processor core; coupling the virtual prototype to a virtual test bench having a graphical representation of a human/machine interface for interacting with the embedded system; publishing the virtual prototype as a functional specification from which a vendor may initiate a simulation of the operation of the embedded system.
69. The method of claim 68, wherein the virtual prototype is stored on a computer readable medium and publishing the virtual prototype comprises sending the computer readable medium to a vendor.
70. The method of claim 68, further comprising a network server, wherein the virtual prototype is published by posting the virtual prototype as a design hosted on a database coupled to the network server.
71. The method of claim 70, wherein the virtual prototype is published to a bulletin board of the database.
72. The method of claim 71, wherein the bulletin board is a bidding board.
73. The method of claim 70, wherein the virtual prototype is published to a database having a matching engine.
74. A computer-implemented method for a vendor to acquire information for the procurement of a good or service related to an embedded system project, the method comprising: accessing a database of virtual prototypes of embedded systems, each of the virtual prototypes having a processor simulator, a finite state machine representation of hardware peripherals, and a virtual test bench emulating a human/machine interface for interacting with a simulation of the operation of the virtual prototype; instantiating an instance of one of the virtual prototypes; and evaluating the virtual prototype.
75. The method of claim 74, further comprising: submitting a quote for a good or service related to the embedded system simulated by the virtual prototype.
76. The method of claim 74, wherein the virtual prototype is configured to show a parts list.
77. The method of claim 74, wherein the virtual prototype is configured to show a component net list.
78. The method of claim 74, wherein the database of virtual prototypes is hosted on a network server accessible by a client computer.
79. A computer-implemented method for evaluating at least one component of an embedded system, the method comprising: forming a virtual embedded system including an instruction set accurate simulator of a target processor core coupling read, write, and interrupt signals with a finite state machine (FSM) representation of a hardware element; coupling a virtual test bench emulating a human/machine interface to the virtual embedded system, the virtual test bench having a graphical user interface adapted to interact with the virtual embedded system; hosting the virtual embedded system on a network server accessible from a client computer via the Internet; uploading from the client computer a binary executable program file of a software application compiled for the target processor core; and responsive to a request from a user, running a simulation of the operation of the virtual embedded system executing the uploaded software application.
80. The method of claim 79, further comprising: forming content for explaining the operation of the embedded system; and responsive to a request from a user, sending the content to the client computer.
81. The method of claim 79, further comprising: responsive to a request from the client computer, forming a persitent data connection between the network server and a client computer; receiving command and data user inputs from a web browser residing on the client computer; and providing graphical display data of the simulation running on the server to the web browser residing on the client computer.
82. The method of claim 79, further comprising: monitoring the user's interaction with the virtual with the virtual embedded system; and recording as marketing data at least one interaction of the user with the virtual embedded system.
83. The method of claim 79, further comprising: forming a plurality of virtual embedded systems in a library; receiving a request form a user for a selected virtual embedded system; and recording data associated with usage of the selected virtual embedded system.
84. The method of claim 83, further comprising: requesting the user to submit registration data and associating the registration data with the marketing data.
85. The method of claim 84, further comprising: providing the user a graphical interface having a design language including a plurality of graphical symbols adapted to form a finite state representation of a user-defined hardware element that may be coupled to the virtual embedded system; monitoring modifications made by a plurality of users to the virtual embedded system; and determining a popular modification to the virtual embedded system.
86. A computer program product for simulating an embedded system, the computer program product comprising: a computer readable medium: a processor simulator module stored on the medium having an instruction set accurate simulator for at least one processor core; a design application module stored on the medium for designing a virtual prototype of the embedded system having an instruction set accurate simulator of at least one processor core coupling read, write, and interrupt signals with a finite state machine (FSM) representation of at least one hardware element; a simulation engine module for executing a simulation of the virtual prototype; a software debugger module stored on the medium for a user to load compiled program code for execution on the virtual prototype; and a test bench module stored on the medium for forming a virtual test bench having a graphical representation of a human/machine interface for interacting with an embedded system prototype.
87. A computer program product for providing information on the operation of an embedded system, comprising: a computer readable medium; a hardware description of the virtual embedded system stored on the medium, the hardware description including an instruction set accurate simulator of a processor core coupling read, write, and interrupt signals with a finite state machine (FSM) representation of at least one hardware element; a simulation engine module stored on the computer readable medium for forming a simulation of the embedded system running a software application on the hardware description; and a test bench module stored on the medium for forming a virtual test bench emulating a human/machine interface to the simulation of the embedded system, the virtual test bench having a graphical user interface adapted to interact with the simulation of the embedded system.
88. A computer program product for evaluating an embedded system, comprising: a computer readable medium; at least one executable file of a hardware description of a virtual embedded system stored on the medium, the virtual embedded system including an instruction set accurate simulator of a processor core coupling read, write, and interrupt signals with a finite state machine (FSM) simulation of at least one hardware element; a simulation engine module for running the at least one executable file as a simulation of the embedded system; and a test bench module stored on the medium configured to forming a virtual test bench emulating a human/machine interface to the virtual embedded system, the virtual test bench having a graphical user interface adapted to interact with the virtual embedded system.
Description
[0001] This application claims priority from U.S. Provisional Application No. 60/208,900, entitled "Method and System For Online Virtual Prototyping," filed Jun. 2, 2000, and U.S. Provisional Application No. 60/230,171, entitled "Method and System For Online Virtual Prototyping With Walkthrough Function," filed Sep. 1, 2000. The entire contents of U.S. Provisional Application Nos. 60/230,171 and 60/208,900 are hereby incorporated by reference in their entirety.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention relates generally to computer implemented electronic design automation techniques to evaluate, design, and simulate embedded systems. More particularly, the present invention is directed towards the use of computer implemented techniques for the evaluation of Intellectual Property components used in embedded systems, the design of embedded systems, and the procurement of goods and services related to an embedded system.
[0004] 2. Description of Background Art
[0005] There is increasing interest in embedded systems. An embedded system is a specialized computer system that is typically part of a larger system or machine. An embedded system requiring custom software is also sometimes described as a "platform." Embedded systems are used in industrial control systems, consumer products (e.g., mobile phones and computer game consoles), and telecommunication systems.
[0006] An embedded system may include its own operating system or, in some cases, a single computer program. An embedded system commonly includes one or more microprocessors, peripheral hardware to perform input/output functions, and several software layers (e.g., device drivers, middleware, or applications). An embedded system having all of the hardware and software residing on a single chip is sometimes called a system on a chip (SOC). However, an embedded system can also be implemented as one or more printed circuit boards with the hardware components implemented as discrete integrated circuit chips.
[0007] Embedded system design includes the design of both hardware and software that must work together in the final product. Typically, the task of designing an embedded system is divided into the separate but complementary tasks of designing the hardware and the software, what is called the "hardware partition" and the "software partition." The design of the hardware partition is facilitated by using as many commercially available hardware components as practical. In particular, the design of an embedded system is increasingly characterized by the use of pre-designed intellectual property (IP) components. An IP component (sometimes also known as an "IP block") is commonly used to describe a component of an embedded system that is licensed to others as intellectual property. However, the term IP component is also sometimes used by engineers to describe a portion of an embedded system that is available from others. For example, a variety of companies license designs for a processor core. Thus, an embedded system designer may select a processor core suitable for an intended application and then design the remaining hardware (e.g., peripherals and buses) to implement the hardware portion. It is common for at least one portion of the hardware to be customized for a particular project. The software partition of an embedded systems project may use portions of software applications from other projects. However, typically a significant amount of code must be written for the software partition of a particular project.
[0008] FIG. 1 illustrates an exemplary embedded system design project 100
that may be divided into sequence of project phases. Exemplary times common for each phase are included on the left-hand side of the illustration. In a requirement definition phase 102, a set of requirements 104 is developed for a product idea 101. Key IP components must then be evaluated for possible use in the embedded system. Because of the nature of embedded system design, documentation alone is typically insufficient to understand how an IP component, such as a processor core, will function with a software application running user code. Consequently, the initial evaluation phase 106 may last up to several months in order to have sufficient time to identify useful IP components and to physically test the operation of software in a working test platform.
[0009] FIG. 2 is a flow chart showing in more detail some of the elements of a conventional evaluation phase 106. For the case of processor cores, this has conventionally involved identifying potential suppliers 202, contacting suppliers to request information 204, ordering and reviewing product information 206, ordering and purchasing an evaluation board 208, receiving the evaluation board, 210, installing the evaluation board 212, installing software development tools 214, customizing the evaluation board 216, running evaluation software on the test board 218, and selecting suppliers 220. Note that the supplier must also commit significant resources to provides services to prepare and send product information 222, receiving orders 224, processing orders 226, and shipping evaluation boards 228. Additionally, support must be provided to users to use the evaluation boards (not shown in FIG. 2). The resources that a vendor must devote also include the resources to design, manufacture, and keep in stock a supply of evaluation boards. In some cases, a significant time delay may be involved for a vendor to arrange for evaluation boards having custom silicon and printed circuit boards to be designed and manufactured. Moreover, each evaluation board may have a significant cost (e.g., thousands of dollars) such that a vendor will only maintain in stock a limited number of evaluation boards at any one moment of time. Consequently, in some cases embedded system designers may have to wait substantial periods of time to obtain an evaluation board.
[0010] From the standpoint of the embedded system designer, the evaluation phase 106 is a time consuming and costly process, particularly if a significant number of IP blocks from different vendors are to be evaluated. Conventionally, evaluating IP blocks from different vendors requires evaluating the operation of separate evaluation boards for each IP block. In addition to being a time consuming process, each IP block can be evaluated only in isolation, which can make it difficult to determine how several IP blocks would interact together in a single embedded system. From the perspective of the IP vendor this is a costly marketing tool that requires IP vendors to invest in creating standard test board platforms (e.g., boards including reference peripheral devices and driver applications). The cost to the IP vendor includes the cost of the evaluation boards and the support services that must be provided for potential customers to successfully evaluate each board.
[0011] After key IP components are selected, a development phase 110
begins, which commonly lasts 3-9 months. The development phase 110
commonly begins by defining the architecture 108 of the embedded system, with the system architecture including, for example, the processor(s) to be used, hardware peripherals, and user interfaces. The hardware architecture may be used to form an initial partition of the hardware and software. Conventionally, hardware development 112 proceeds faster than software development 114 because software developers need a hardware implementation to develop some types of software.
[0012] FIG. 3 is a flow chart showing in more detail some of the aspects of the development phase 110. After the system architecture is defined 108, specification documents 302 for both the hardware and the software partition are created. The hardware development begins by developing hardware components 304. Software engineers may use an evaluation board to develop some of the software application layers 352 but cannot start developing certain types of software (e.g., middleware and device drivers) until a hardware emulation prototype 308 is available. Other steps common in the subsequent hardware and software development are indicated on FIG. 3. Typically, the hardware must reach a high level of implementation detail before a hardware emulator having sufficient speed may be developed 306 for continued software development 354 (e.g., middleware, device drivers) to proceed. The hardware partition is commonly emulated using hardware emulation boards and hardware acceleration boxes, which feature a combination of re-programmable hardware, typically in the form of Field Programmable Gate Arrays (FPGA), and plugable modules/boards containing the processor(s) that will emulate the hardware partition.
[0013] Hardware emulators are commonly a factor of 100 or more slower than the final physical system but provide sufficient speed to debug software. Unfortunately it may take up to two-thirds of the development cycle before the hardware implementation reaches a high level of implementation detail and a physical hardware emulator 308 is configured. This means that feedback 356 to refine hardware components 310 comes later than desired. Moreover, early software integration 358 must wait until hardware components have been fabricated 312 and a PCB prototype designed 314 and fabricated 316. After the results of the early PCB prototype 360, hardware development proceeds 318, 320, 322, and 324 towards a final PCB prototype upon which final software integration and testing 360 may be performed. Note that FIG. 3 assumes that hardware emulator is used. However, a conventional hardware emulator is comparatively expensive. In some embedded system projects a hardware emulator (e.g., a FPGA hardware emulator) may not be cost effective such that much of the software development and integration must wait until a physical prototype is available.
[0014] Referring again to FIG. 1, note that the procurement of many goods or services required for the manufacture of an embedded system often must wait until a tested prototype 120 is available after a quality assurance and testing phase 118. Procurement significantly earlier than the tested prototype stage 120 is typically impractical because there is an insufficient quantity and quality of documentation prior to the tested prototype stage that would permit procurement needs to be adequately communicated with vendors. The procurement phase 122 may include purchasing components, PCB boards, IP licenses, and arranging for semiconductor fabrication of custom silicon chips required for a manufacturing and assembly phase 126 to produce a final product 128 on a pre-product definition 124.
[0015] Embedded systems designers are under increasing pressure to reduce the time to market and to increase the software functionality of embedded systems, which in turn tends to increase the complexity of embedded system software. Embedded system design projects would be facilitated if there were a computer aided design tool that permitted the efficient selection of a processor core or other IP components, facilitated the co-design of both the hardware and software partition, and facilitated the procurement of IP components and other necessary services. However, conventional automated design tools have serious shortcomings that limit their usefulness in the design cycle, particularly for embedded systems executing complex software applications. Moreover, conventional automated design tools also have shortcomings in speed, user-friendliness, and security that have hindered the development of web-based design tools.
[0016] One drawback of conventional electronic design approaches for embedded systems is that they are hardware-centric and typically have an execution speed that is too slow for the simulation to serve as a hardware emulator for the purposes of debugging software. For example, one conventional electronic design method is to use a hardware definition language (HDL) to model the hardware partition at the hardware implementation level. However, modeling the hardware implementation in HDL requires that the hardware be extensively developed (e.g., fully detailed) before the software, which can require a significant length of time in the development cycle.
[0017] In addition to its other problems, a HDL simulation (e.g., one using a cycle-accurate processor model and a detailed implementation model of hardware) has such a high level of implementation detail that a software application executed on HDL simulation of the hardware partition would be too slow for meaningful software debugging during a typical development phase. As one example, a software application running on virtual hardware needs a comparatively high execution speed to detect deadlocked situations between multiple on-chip processors. As another example, a software application running on virtual hardware needs a comparatively high execution speed to perform a booting test of a full-fledge operating system (OS) on the hardware being designed. However, HDL models typically execute at too slow a speed to permit a software designer to evaluate the system aspects in which a software designer is interested.
[0018] A further drawback of HDL models is that it is often impractical to share them with third parties that are not legally bound to maintain the confidentiality of the model. An HDL description of an embedded system includes implementation details required to fabricate an end product. HDL models have such a high level of implementation detail that companies are reluctant to share HDL models with other companies for fear of losing valuable proprietary trade secrets. As one consequence, IP vendors typically do not provide HDL models of their products for evaluation. Another consequence is that embedded system designers and IP vendors typically do not make HDL models of IP components and sub-systems available on the Internet.
[0019] The problems associated with conventional embedded system design projects can be anticipated to become worse as improvements in the processing power of embedded systems permits embedded systems having more complex software applications. This can be expected to increase the need to rapidly and effectively evaluate IP blocks during the evaluation phase, to accelerate the pace of software development during the development cycle, and to improve the procurement of goods and services related to the embedded system project, including the licensing of IP blocks. However, conventional automated design tools do not provide the right level of abstraction, quick model creation, ease of use, execution speed, and understandability to permit substantial improvements in the evaluation, development, and procurement phases of an embedded system design project.
[0020] What is desired is a computer-aided system and method for improving the evaluation, development, and procurement phases of an embedded system development project.
SUMMARY OF THE INVENTION
[0021] An integrated design environment (IDE) is disclosed for simulating embedded systems. The IDE includes a graphical user interface and a design language for forming finite state machine models of hardware components that are coupled to processor simulators, preferably instruction set accurate simulators of processor cores. In one embodiment, the design language has graphical symbols adapted from the specification design language, is configured to reduce simulation overhead, and also includes features for modeling the signals of hardware elements. A virtual test bench may be coupled to the simulation to serve as a human-machine interface for interacting with the simulation. In one embodiment of virtual test bench, the virtual test bench includes a graphical representation of a user input interface and a graphical representation of an output display. A software debugger permits software to be loaded and executed for the simulation. In a preferred embodiment, the software debugger is adapted to permit at least one binary program code of a software application compiled for a target processor to be loaded by a user and executed on the virtual embedded system. One application of the IDE is to form a virtual embedded system having an execution speed sufficiently high to permit the evaluation of benchmark software executing on the virtual embedded system. In one embodiment, a virtual embedded system emulates the function of a physical evaluation board so that a virtual embedded system may be used to evaluate components of an embedded system, such as a processor core, in an evaluation phase of an embedded system project. Another application of the IDE is to form a virtual prototype of an embedded system having an execution speed sufficiently high to permit the virtual prototype to be used to develop software. In a preferred embodiment, a user may execute production quality embedded system code on the virtual prototype. In one embodiment, a virtual prototype is used during a development phase of an embedded system project to develop software. Still another application of the IDE is to form a virtual prototype that may be used as a design specification. In one embodiment, the virtual prototype is used as design specification to coordinate the actions of hardware and software developers during a development phase of an embedded system project. In another embodiment, the virtual prototype is used as a design specification for the procurement of a good or service related to the embedded system.
[0022] The IDE may be hosted on a network server accessible from a client computer. In one embodiment a persistent virtual channel may be formed between the client computer and the network server for executing the IDE on the network server. In one embodiment, a user may use the IDE to create a design and store executable files associated with the design in a design repository. In one embodiment of a collaborative method of designing embedded systems, an administrator may grant access privileges to the design to members of a user group. In one embodiment, designs of embedded systems or sub-systems are stored in a library and made accessible to other users. Additionally, in one embodiment a vendor of a component for an embedded system may design and store executable files of virtual embedded systems for demonstrating the operation of the component in a library coupled to the network server.
[0023] In one embodiment, the network server is coupled to the Internet, permitting the IDE to be offered as a web-hosted service. An on-line bulletin board may be coupled to a server for hosting designs. In one embodiment, the on-line bulletin board includes a bidding board for a vendor to access a design published by a designer on the bidding board. In a preferred embodiment, a designer may select the access privileges of vendors to the design. In a preferred embodiment, a vendor may receive a request for quote that includes access privilege to the design.
[0024] In one embodiment of a web-based service for providing evaluation services, one or more virtual embedded systems for evaluating components of an embedded system are stored in a library coupled to a web server. Users may select a virtual embedded system, modify the virtual embedded system, and run a simulation of the embedded system. In a preferred embodiment the on-line behavior of users is recorded to form data on the usage of the virtual embedded systems. The usage behavior may be converted into marketing data, such as data on preferred processor cores and hardware peripherals.
[0025] The features and advantages described in the specification are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] FIG. 1 is a flow chart showing a conventional embedded system design cycle.
[0027] FIG. 2 is flow chart showing in more detail the evaluation phase for the conventional embedded system design cycle of FIG. 1.
[0028] FIG. 3 is a flow chart showing in more detail a conventional hardware/software development phase for the conventional embedded system design cycle of FIG. 1.
[0029] FIG. 4A is a block diagram of major software modules of an integrated design environment (IDE) and FIG. 4B is an illustrative figure of applications for the IDE.
[0030] FIG. 5 is a flow chart showing a preferred method of designing an embedded system in accordance with the integrated design environment of the present invention.
[0031] FIG. 6 is a detailed flow chart of a preferred method of evaluating intellectual property for the design method of FIG. 5.
[0032] FIG. 7 is a detailed flow chart of a preferred method of hardware/software development for the design method of FIG. 5.
[0033] FIG. 8 is a detailed flow chart of a preferred method of procurement for the design method of FIG. 5.
[0034] FIG. 9 is a conceptual block diagram of an integrated development environment for designing virtual prototypes of embedded systems.
[0035] FIG. 10 illustrates the formation of an object file of a hardware description for a discrete event simulation engine.
[0036] FIG. 11 is an illustration of the architecture of an integrated design environment.
[0037] FIG. 12 is a top level flowchart of the a method of using the integrate design environment.
[0038] FIG. 13 is a flow chart of a sub-task of FIG. 12.
[0039] FIG. 14 is a flow chart of a sub-task of FIG. 12 for simulation and debugging.
[0040] FIG. 15 is a screen shot of an IDE design window, showing the details of a finite state machine representation using graphical constructs.
[0041] FIG. 16 shows examples of a block construct having a process, devices, and a declaration constructs.
[0042] FIG. 17A shows a conventional finite state machine representation of a hardware peripheral in a transition condition/action format.
[0043] FIG. 17B shows the finite state machine of FIG. 17A written using graphical constructs in accord with the present invention.
[0044] FIG. shows two communicating finite state machines with implicit signal queues explicitly drawn.
[0045] FIGS. 19A and 19B are a table showing graphical objects of a preferred design language.
[0046] FIG. 20 is a screenshot showing an example of a finite state machine representation of a hardware counter peripheral.
[0047] FIG. 21 is a screen shot of a main window of a preferred design window and toolbars.
[0048] FIG. 22 is a screen shot showing a preferred standard toolbar for the integrated design environment.
[0049] FIG. 23 is a screen shot of a preferred navigation and symbol editor toolbar.
[0050] FIG. 24 is a screen shot of a preferred toolbar for forming finite state representations of hardware components.
[0051] FIG. 25 is a screen shot of a preferred compiler debugger toolbar.
[0052] FIG. 26 is a screenshot of a preferred testbench builder toolbar.
[0053] FIG. 27 is a screen shot of a message window showing different message the status bar.
[0054] FIG. 28 is a screen shot of a base station for a cordless handset showing the top-level block diagram opened in the design window.
[0055] FIG. 29 is a screen shot of a processor with an interrupt controller and a peripheral.
[0056] FIG. 30 shows screenshots of a preferred design, signal, and connectivity
[0057] FIG. 31 is a screenshot of the design browser showing details of a library browser.
[0058] FIG. 32 is a screen shot of a project library manager window.
[0059] FIG. 33A is a screen shot of a waveform viewer tool for viewing signal occurrences and values of variables on a time axis.
[0060] FIG. 33B is a second screen shot of a waveform viewer tool.
[0061] FIG. 34A is a screen shot showing a test bench editor window (right), and a test bench control library (left).
[0062] FIG. 34B is a screen shot of a virtual test bench.
[0063] FIG. 34C is a screen shot of a virtual test bench.
[0064] FIG. 35 is an illustrative diagram of the operation of a simulation cockpit.
[0065] FIG. 36A is a screen shot showing the execution of a simulation with multiple windows opened.
[0066] FIG. 36B is an illustrative screen shot showing an opened software debugger interface superimposed over an embedded system design.
[0067] FIG. 36C is an illustrative screen shot illustrating how a breakpoint of execution may be associated with a graphical construct of the finite state representation of the hardware components.
[0068] FIG. 37 is a conceptual illustration of a processor integration interface.
[0069] FIG. 38 is a screenshot of the top-level diagram of a (ARM) processor and two peripherals.
[0070] FIG. 39 is a screenshot of a processor IO Configurator Wizard.
[0071] FIG. 40 is a detail of a screen shot of of the Processor IO Configurator Wizard.
[0072] FIG. 41 is a block diagram of a client-server architecture and components for virtual prototyping.
[0073] FIG. 42 is a block diagram of the client-server architecture and components for an Internet deployment of on-line virtual prototyping.
[0074] FIG. 43 is a screenshot of a virtual prototyping window deployed through a web browser.
[0075] FIG. 44 is a diagram of a network architecture and software modules for collaborative design.
[0076] FIG. 45 is a table of icons for a signal browser.
[0077] FIG. 46 is a block diagram of a test bench coupled to a simulation.
[0078] FIG. 47 is a flow chart showing how test bench controls and variables may negotiate a communication interface.
[0079] FIG. 48 is a block diagram of an interactive walkthrough embodiment.
[0080] FIGS. 49A-49J are screen shots of an interactive walkthrough of an embedded system.
[0081] FIGS. 50-55 are screen shots of an example of an on-line embodiment.
[0082] The figures depict a preferred embodiment of the present invention for purposes of illustration only. One of skill in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods disclosed herein may be employed without departing from the principles of the claimed invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0083] The present invention generally includes a computer-implemented technique for simulating an embedded system using a graphical integrated development environment (IDE) design application that has features for rapidly creating and evaluating virtual embedded systems (also known as "virtual platforms" or "virtual prototypes" for new designs) and that has a sufficient simulation speed and test features to permit evaluation, development, and debugging of an embedded system software application to be performed with a virtual embedded system.
[0084] FIG. 4A is a block diagram illustrating major software modules of a preferred embodiment of the IDE 402. Further details on the interfaces coupling the software modules are described below in more detail. The software modules of IDE 402 may reside on a memory 450 of a computer 460
having a computer processor and memory, such as personal computer or computer coupled to a network server. It will also be understood that the IDE 402 may be stored as a software application on a computer readable medium, such as a compact disk.
[0085] The IDE 402 may be conceptually divided into a user design portion 482 and a simulation portion 486 that communicate with each other through process boundary 488. IDE 402 preferably includes a graphical user interface (GUI) software module 420 for a user to interact with IDE 402. An editor and debugger module 470, design database module 472, code generator module 474, and compiler module 476 may be coupled to GUI software module 470 as a hardware design and modeling module 478 for forming a description of the hardware partition of an embedded system.
[0086] A simulation loader module 422 invokes other IDE modules when a simulation of an embedded system is initiated from GUI module 420. A command input module 424 receives commands from the GUI module 420 and passes them on to a command router module 426, which selects whether the command is routed to a scheduler processor simulator module 432, scheduler module 430, or simulation engine module 436. A message output module 428 communicates messages from the processor simulator module 432
and the simulation engine module 436 to GUI module 420. The scheduler module 430 coordinates the actions of the processor simulator module 432
and the simulation engine 436, providing global execution control for the virtual system. The processor simulator module 432 includes a processor simulator, preferably an instruction set accurate processor simulator, for each processor core in a library of processor cores and is configured to decode an instruction stream residing in a virtual memory. As shown in FIG. 4A, several processor simulator modules 432 may be included to support the simulation of more than one processor core. A processor simulator module 432 may have an associated slave component module 434
such as cache or memory model. The simulation engine module 436 provides simulation services to execute a simulation and is described below in more detail. As described below in more detail, in one embodiment the hardware description may include one or more dynamic link library files. Consequently, in this embodiment, component DLL modules 438 of the hardware description are dynamically loaded by the simulator loader. A simulation cockpit module 440 loads test bench controls and provides a simulation cockpit window for a user to interact with a virtual system.
[0087] A software debugger module 442 provides a debugging interface with the processor simulator, allowing the software debugger module to control the execution of the processor simulator and perform other software debugger functions, such as displaying register values. In a preferred embodiment a software debugger permits embedded system software to be loaded for execution on the processor simulator of the virtual embedded system. In one embodiment, the software debugger is adapted to permit a user to load and execute binary program code of a software application compiled for a target processor.
[0088] Referring to FIG. 4B, IDE 402 may also be part of a computer system having additional tools 405 and on-line technology 401 to provide a variety of services 403 related to the evaluation, development, and procurement phases of an embedded systems project. As illustrated in FIG. 4B, in one embodiment IDE 402 is used to provide services associated with the evaluation, development, or procurement phases of an embedded system project. These services may include intellectual property aggregation 404, procurement services 406, geographically distributed co-development 408, marketing of goods or services related to embedded systems 410, and evaluation of IP components (e.g., processor cores) 412. In one embodiment the services are offered as a web-based service with the IDE residing on a network server. However, it will be understood that some of the functions of a web-based service may be emulated by exchanging data files using other techniques, such as by shipping executable files on a computer readable medium (e.g., a CD), making executable files available via a file transfer protocol (FTP) technique, or by sending data files via e-mail. Moreover, it will also be understood that the IDE may use to provide one or more services to other types of networks, such as a local area network, wide area network, intranets, or extranets.
[0089] FIGS. 5-8 show methods of using the IDE of the present invention in an embedded system design project and FIGS. 9-49 show details of the IDE and its use. The IDE of the present invention has features for rapidly creating virtual embedded systems, which permit the virtual embedded systems to be used to evaluate the operation of an embedded system executing user code loaded onto the virtual embedded system. This permits embedded systems to be designed in new and more efficient ways.
[0090] FIG. 5 is an illustrative flow chart of showing some of the ways that the IDE 402 of the present invention may be used in an embedded system design project, preferably as part of a web-based service. Illustrative times for the completion of each phase of an embedded system project are shown. As shown in FIG. 5, the evaluation phase 106 of an embedded system project may be improved by using the IDE of the present invention to provide virtual embedded systems ("virtual platforms") for evaluating intellectual property (IP) components 502, preferably as part of a web-based service. This leads to a reduction in the time required for evaluating IP components and/or allows larger numbers of IP components to be evaluated compared to the conventional approach of using physical test evaluation boards. As an illustrative example, an evaluation phase 106 that would conventionally require 1-3 months using physical evaluation test boards may be reduced to about 1-2 weeks using virtual embedded systems to evaluate IP components.
[0091] FIG. 6 shows in greater detail some of the aspects of a preferred embodiment for providing an on-line evaluation service. Referring to FIG. 6, in one embodiment of the present invention the IDE 402 may be used during the evaluation phase 106 of an embedded system project to provide a simulation of an embedded system for evaluating IP components 502, such as processor cores. The IDE and associated tools and services may be used to select models of IP components and virtual platforms 636, to customize virtual platforms 638, to load and execute benchmark software on the virtual platforms 642, and to evaluate the operation of the embedded system platform using virtual test benches 640 and debugging tools 644. As described below in more detail particularly in regards to web-based embodiments, the use of virtual prototypes for evaluating IP components provides many benefits in terms of time, cost, and convenience for evaluating IP components compared with the conventional approach of using physical evaluation test boards and physical test hardware to evaluate IP components.
[0092] Referring again to FIG. 5, the present invention may also be used to form a virtual prototype of an embedded system early in a development phase 110 of an embedded system project. The virtual prototype can be used to evaluate and debug software before hardware implementation details are sufficiently developed to program a conventional FPGA hardware emulator. A conventional FPGA hardware emulator requires substantial hardware implementation details and may also require a significant physical set-up time, which typically makes the FPGA hardware emulator unavailable for software debugging for many months into the development cycle. Consequently, by using a virtual prototype for early software development, significant savings in time and/or improvements in software quality may be achieved. Thus, in the illustrative example of FIG. 5, the present invention permits a reduction of 1-to-4 months in the development time compared with a conventional embedded system project relying upon FPGA hardware emulators such as that shown in FIG. 3. Also, since a conventional FPGA hardware emulator is comparatively expensive, the present invention provides a substantial cost savings compared to a conventional FPGA hardware emulator.
[0093] FIG. 7 is a more detailed flow chart of a method of using virtual prototyping in a development phase. Referring to FIG. 7, one aspect of the present invention is an IDE 402 for rapidly developing a virtual prototype 704 of an embedded system early in the prototype phase 110
(e.g., after the architecture definition 108), with the virtual prototype 704 executing a software application with sufficient speed to permit the virtual prototype 704 to be used to develop software early in the development phase 110 and to provide early feedback to hardware designers.
[0094] As illustrated in FIG. 7, the hardware designers can begin to develop hardware components using the virtual prototype 704 as an executable specification. Correspondingly, the software developers may use the virtual prototype 704 for early software development 352 (e.g., application layers, middleware, and device drivers), continued software development 354 (e.g., middleware and device drivers), and for early software integration 358 (i.e., evaluating system-level operation of the embedded system with an early version of the final software). This can be used to provide early feedback 356 to hardware developers to refine the hardware components. Note also that if there are any flaws in the early PCB prototype 360 revealed during physical board testing 362 that the virtual prototype 704 may be modified and used for final software integration 370. Comparing FIG. 7 with the conventional approach of FIG. 3, it can be seen that seen that the use of a virtual prototype in accordance with the present invention may be used to accelerate the development of software development and integration, thereby beneficially reducing the time required for the development phase 110 and/or increasing the quality of the final embedded system.
[0095] Referring again to FIG. 5, a virtual prototype 704 developed for the development phase 110 may also be used to improve the procurement process by using the virtual prototype as an executable functional specification in an early procurement phase 560. The virtual prototype may, for example, be used by a PCB board manufacturer, component distributor, semiconductor fabrication company, or other group 504 to understand the function of the embedded system at a high level of abstraction, i.e., from the viewpoint of major components, signals, and their interactions. Since an interactive virtual prototype may be created early in the development phase 110 before a tested (physical) prototype is available, several weeks or more may be saved compared to a conventional procurement phase. FIG. 8 in more detail a preferred embodiment for using a virtual prototype as part of a procurement system for submitting request for quotes for goods or services related to an embedded system project. In a preferred embodiment, the procurement system may be part of a web-based service.
[0096] FIG. 9 is a conceptual illustration of one embodiment of a graphical IDE 402 of the present invention. Referring to FIG. 9, processor simulators for one or more processor cores 902 are stored or accessible from a library of processors. In one embodiment, other IP components, such as models of hardware peripherals, may also be stored in a library 904. The IDE preferably includes a library having at least one IP block, including at least one processor simulator that a designer may select. The processor simulator is a model simulating the function of a processor core and, if desired, additional elements associated with the processor core. As described below in more detail, in a preferred embodiment, a processor core is modeled as a high speed instruction set accurate (ISA) simulator. A peripheral editor and discrete event simulator 906 is used to execute an object file of a hardware description 908. The hardware description is preferably created with graphical constructs in what the inventors call the "MAGIC-C" language. As illustrated in FIG. 9, the peripheral editor and simulator 906 may include models of the hardware peripherals and busses, I/O modules, hardware accelerators, processor glue logic and custom IP. A test bench builder 910 permits a virtual test bench having a graphical interface emulating a human/machine interface to be displayed to a user.
[0097] FIG. 10 shows a preferred embodiment of a discrete-event simulation engine 1002 for executing the simulation is optimized for system-level simulation at software execution speeds preferably exceeding millions of instructions per second. A hardware modeling environment (not shown in FIG. 10) is used to create a hardware specification from which an object file for the hardware specification 1004 may be compiled for execution on a discrete event simulation engine 1002. As described below in more detail, in a preferred embodiment, finite state machine representations of the hardware specification 1006 are created using graphical object "constructs" that have a graphical portion and a textual portion for defining their function. In one embodiment, the graphical constructs may include user-defined high level descriptions of task behavior (e.g., C/C++ models) and shapes adapted from the specification and description language (SDL). Consequently, a graphical database 1010 and behavior database 1012 is included to generate code for the hardware specification. As indicated in FIG. 10, a design editor 1008 accesses graphical constructs from a graphical database 1010. A user may input code describing the function or attributes of a graphical construct along with inputs/outputs to a graphical construct. A code generator 1016
(e.g., a C++ code generator) and compiler 1018 is used to generate an object file of the final hardware specification, that is linked in the simulation engine, resulting in a compiled code simulation executable. In another embodiment, separate dynamic link library (DLL) files may be generated for portions of the hardware specification (e.g., for each symbol or component) that are loaded at start-up by a simulation loader to form the simulation. If desired, an export back-end APIs 1022 may be included to allow a user to traverse and access the internal design database. This enables users to build their own code generator 1024 for different languages (i.e., should language other than the preferred implementation in C++ be desired).
[0098] FIG. 11 is a block diagram illustrating in more detail some of the operation of the discrete event simulation engine 1002. Referring to FIG. 11, an open simulator Application Procedure Interface (API) 1102 is preferably included to communicate memory transactions (i.e., read and write operations) from ISA simulators of processors 1120 to the FSM peripheral models in one direction, and interrupts from the peripheral model to the processor model in the other direction. Additional APIs 1104, 1106 may be included for coupling a test bench to the discrete event simulation engine and for coupling a software debugger 1130 to an instruction set accurate simulator of a processor.
[0099] As shown in FIGS. 28, 29, and 37, the use of an instruction set accurate simulator to model a processor core permits the processor simulator to exchange memory transactions with the hardware partition and to receive interrupts from the hardware partition using APIs linking the hardware partition and the instruction set accurate simulator. A configuration to map address spaces from the virtual processor core to the virtual hardware is part of the IDE. One advantage of an instruction set accurate simulator is that it permits user binary program code (e.g., a binary program executable of a software application) to be compiled for the target processor and to be loaded and executed by the processor simulator at a high rate of execution (e.g., 1-10 MIPS running the simulation on a computer system having a high speed microprocessor). This is fast enough for software developers to explore software issues of production quality code (e.g., software execution and debugging). For example, with the IDE running on a PC having a 450 MHz microprocessor, the simulation has a sufficient execution speed to boot a typical embedded system operating system (e.g., WINDOWS NT or LINUX) in less than 60 seconds, with less than 30 seconds being a typical booting time. As shown in FIGS. 11 and 36, APIs may be used to couple a debugger to the instruction set simulator. In one embodiment, a user may associated breakpoints of execution in the FSM representation of a hardware element and may select signals of the hardware partition for viewing in a waveform viewing. This improves the ability of a user to debug hardware and software. In one embodiment, the ability to set breakpoints and perform single-step debugging allows the designer to stop the entire system simulation at any point in either the software or hardware domain. A virtual test bench 1120 may be coupled by an API 1104 to the virtual hardware partition.
[0100] Referring to FIGS. 12-13, in a preferred embodiment, the IDE permits a user to model hardware elements and processes as blocks, processes, or symbols. FIG. 12 is a flow chart 1200 of an exemplary design process for creating a virtual prototype 702, which includes designing a functional specification of an embedded system 1210, creating test benches 1220, generating code 1230, and simulating and debugging the virtual prototype 1240. FIG. 13 is a more detailed flowchart of some of the steps in the design process 1210 for creating FSM representations of blocks, processes, and symbols in the MAGIC-C language. FIG. 14 is a flowchart showing steps for setting breakpoints and debugging during the simulation and debugging of a virtual prototype 1240. In a preferred embodiment generated code contains extensive debugging hooks, allowing graphical debugging of FSM code and providing advanced debugging features as single-stepping and breakpoint placement directly on the graphical constructs, and this in the same Design editor window which was used to create the FSM specification. In one embodiment, the C source file implements the FSM model using a skeleton build around a single switch statement and a breakpoint macro that reports the state of the FSM to be displayed during simulation and allow the placing of breakpoints and single-stepping.
[0101] Referring to FIGS. 15-26, the IDE includes a graphical design editor having a design language to create an extended finite state machine (FSM) representation of hardware peripherals in the hardware partition. As shown in FIGS. 19A and 19B, in a preferred embodiment the design language is a graphical design language having graphical objects for forming a FSM representation as a series of linked objects representing the FSM. Referring to FIG. 15, in a preferred embodiment the graphical object symbols may be selected from a menu 1520, a textual portion of the object input by the user, and the graphical object connected to other graphical objects using connectors 1505. A preferred embodiment of a graphical design language, known as "MAGIC-C.TM., includes some features of the specification and description language (SDL) adapted to create a hardware description. Referring to FIGS. 21-26, in a preferred embodiment, a menu-driven graphical interface is used to facilitate the creation of hardware peripherals. As shown in FIG. 21, the IDE preferably has a menu-driven graphical user interface that preferably includes a design window for creating a design with toolbars for accessing functions using a computer mouse or similar interface. The IDE preferably includes a peripheral design editor and simulator that is adapted to permit hardware IP components and processes to be created and linked with other IP components.
[0102] In a preferred embodiment, FSM representations of hardware elements may be encapsulated into containers (symbols) having signal pins and connectors that may be labeled to facilitate a high-level functional block understanding of the embedded system but which may also be opened to reveal lower-levels of detail of each symbol or block. FIG. 28 an exemplary screen shot of a top-level block diagram of a cordless phone system showing a cordless phone symbol 2805 with pin symbols 2810. FIG. 29 shows an exemplary screen shot of a processor simulator 2905 coupled to an interrupt controller 2920 and a counter peripheral 2930. Note that the memory read/write transactions from the pins for processor simulator 2905 to counter 2930 may be labeled as well as interrupt signals from the interrupt controller 2920 to the processor simulator 2905. Consequently, a high-level understanding of the embedded system of FIG. 29 may be obtained because it is a high-level functional block diagram of the embedded system and because a virtual test bench may be used to interact with the virtual embedded system. Moreover, in a preferred embodiment a graphical hardware debugger permits the execution to be selected to trace the behavior of the embedded system. FIGS. 30-31 are screen shots of browsers and control windows useful for rapid navigation, traversal, and design of embedded system designs having multiple levels of hierarchy.
[0103] The IDE preferably includes a test bench builder, software debugger, and waveform viewer to emulate other physical test apparatus commonly used to assess the operation of an embedded system. As shown in FIGS. 33A and 33B, a waveform viewer is also preferably included for viewing a selected signal as a function of time. As shown in the exemplary screen shot of FIG. 34A, in a preferred embodiment a test bench builder 3405 is included for forming a graphical representation of a test bench. As used in this application a test-bench builder is an application that allows a designer to build a simulation of an embedded system by adding graphical objects (e.g., buttons, LEDs, LCDs, alpha-numeric keyboards, telephone keypads, register viewers, memory viewers, resource meters, etc.) to mimic a physical human-machine interface of an embedded system product. As examples, a keyboard interface 3410 may permit a user to input commands via the keyboard while an LCD interface may mimic the outputs of a physical LCD. This graphical test builder may be used to inject stimuli into the simulation and observe the system behavior. FIG. 46 is a block diagram showing a test bench interacting with a simulation engine. FIG. 47 is a flow chart illustrating a preferred method for a debug interface to negotiate a communication interface between a test bench control and a variable of the simulation.
[0104] Referring to FIG. 35, during a simulation of an embedded system, a simulation cockpit is preferably included that provides information on the status of a simulation and that loads and updates the test bench objects. Referring to FIG. 36A, a software debugger 3685 is also preferably included for loading and testing software that is executed on the virtual platform. The software debugger 3685 preferably includes means to establish break-points of execution of the software application and to view and modify processor and system resources such as the processor stack, registers, and memory. FIG. 36B shows an example of a software debugger interface window 3685 superimposed over a design window 3620 of a virtual embedded system. As shown in FIG. 34C, in one embodiment a user may select breakpoints of execution 3900 in the hardware description associated with the execution of the simulation reaching a command flow of a particular graphical construct 3980. Referring to FIG. 36A, note that the software debugger 3685, virtual test bench 3605, and design window 3620 of the embedded system may be viewed simultaneously. This provides the benefit that each interface provides a display and control of a different aspect of the system, which is particularly beneficial in developing low-level software routine or when integrating hardware and software partitions.
[0105] As illustrated in FIG. 37, in a preferred embodiment a CPU 10
Configurator 3702 application is included to permit a processor simulator to map addresses spaces to peripheral virtual hardware models such that a processor simulator 3705 communicates read/write memory transactions to the appropriate addresses of virtual hardware such as hardware elements 3720 and 3730, while the virtual hardware sends interrupt signals to the appropriate addresses of the processor simulator 3705. As previously described, in a preferred embodiment, processor simulator 3705 is an instruction set accurate simulator. It will be understood that the mapping of read/write memory transactions and interrupt signals permits the implementation of a high-level model of the embedded system that is sufficient to execute a software application on the virtual embedded system. FIG. 38 is an screen shot of an exemplary processor symbol 3805
and two peripherals 3830 and 3840. FIGS. 39-40 are exemplary screen shots showing a Configuration Wizard and configuration data for coupling read/write memory transactions and interrupt signals between the FSM representation of the hardware peripherals and the ISA processor. Details of the CPU attributes, bus attributes, and other details may be included in the Configuration Wizard. Referring to FIG. 38, a configuration wizard permits a user to rapidly form a high level symbolic diagram of read/write and interrupt interactions that accurately maps signals between address spaces.
[0106] The IDE of the present invention permits a model of an embedded system to be created in a comparatively short time, e.g., within a few hours to a few days for many typical embedded systems. The short model development time is due, in part, to the graphical user interface, which in a preferred embodiment includes numerous features and a powerful FSM design language (MAGIC-C) for rapidly creating FSM models and forming re-usable models. However, another factor is that the level of abstraction is high enough to not require low-level hardware implementation details while still having sufficient software-centric details to execute a user application. This makes the IDE of the present invention consistent with developing a virtual prototype that is a useful functional representation of an embedded system within the comparatively small time allotted in typical projects for evaluating IP blocks and creating an architecture definition. The resulting virtual prototype can be used as a development target for embedded software early in the development cycle, e.g., before any physical hardware or prototype is available. Moreover, as described below in more detail, a user may load production quality code (e.g., binary code compiled for a specific processor) for execution on the virtual embedded system. The high level of abstraction facilitates sharing models of embedded systems with others. One aspect of this is that the level of abstraction is high enough that no hardware implementation details are disclosed, which makes it possible to provide embedded system models to others while still preserving proprietary trade secrets required to manufacture the final end-product. Additionally, the high level of abstraction makes it comparatively easy to understand the function and operation of the embedded system model, which facilitates sharing an embedded system model with others as an evaluation tool or for procurement of goods or services related to the embedded system design.
[0107] As described below in more detail, the high level of abstraction permits the simulation to execute a software application at an acceptably high rate of execution for software debugging, e.g., permits useful software debugging in the first few weeks or months of a development phase. Consequently, a virtual prototype formed in accord with the present invention may be used as hardware emulator for debugging software. Software execution rates in excess of several MIPS may be achieved with the simulation running on computer with speeds of 450 MHz and above. Thus, the virtual prototype is available early in the development phase (e.g., at the architecture definition stage) to function as a hardware emulator for developing and debugging software. By way of comparison, a conventional hardware emulator, such as a FPGA hardware emulator, typically arrives late in the development phase after hardware implementation details are developed (and is sometimes not used at all because of the high cost of a FPGA hardware emulator). Consequently, a virtual prototype in accordance with the present invention makes possible the concurrent development of both the hardware and software partition in the development phase. A large reduction in development time and/or improvements in quality are facilitated because a virtual prototype may be used for early software development, concurrent hardware and software development, and early hardware/software integration. An alternate way of describing these benefits of the present invention is that the creation of a virtual prototype that is a functional specification of an embedded system facilitates true co-design, since hardware designers can use the functional specification to develop hardware implementation details while software designers can use the functional specification to perform early evaluation, early development and debugging of software applications, and consequently early hardware/software integration.
[0108] It will be understood that the IDE of the present invention may be coupled to a network server, such as a web server. FIGS. 41-44 illustrate a preferred implementation of the IDE of the present invention as a web-based service. As shown in FIG. 41, a persistent communication channel may be established between a client computer and a network server. FIG. 42 shows another implementation of a client-server architecture having increased security for web-based service. FIG. 43 is an exemplary screen snapshot of the IDE design window on the browser of a client computer. FIG. 44 is a block diagram illustrating a preferred web-based service including a collaborative design manager.
[0109] In one embodiment, the IDE is used to form virtual platforms for evaluating IP components. In a preferred embodiment, a web-based service is used to market embedded systems components or sub-systems (e.g., a processor core) by hosting virtual platforms on a central server. In one embodiment, a user can use a client computer to access the virtual platform and evaluate the virtual platform executing benchmark software selected by the user, e.g., by executing the simulation and observing the operation of the embedded system using the virtual test bench, debugger, and other tools. In one embodiment, the virtual platform is designed to emulate the function of a reference evaluation board used to evaluate a processor core or other IP component during an evaluation phase of an embedded system project.
[0110] Referring to FIG. 48, in one embodiment an interactive walkthrough content may be associated with a virtual platform to provide content for explaining the operation of a virtual platform. In one embodiment, additional marketing data is recorded and associated with a user's on-line usage an interaction with a virtual platform.
[0111] An on-line IP evaluation service provided benefits to both embedded system designers and vendors. From the perspective of embedded system designers, virtual evaluation saves time compared to conventional evaluation using physical reference boards because virtual evaluation is available on-line (eliminating ordering and shipment delays), because virtual test benches and other evaluation tools facilitate rapid evaluation, and because an on-line IP evaluation service permits IP from multiple vendors to be conveniently evaluated. From the perspective of IP vendors, virtual evaluation saves money and reduces the need for customer support. In particular, there is a low incremental cost to providing a virtual evaluation platform. Additionally, by monitoring the on-line usage and interaction with virtual platforms, IP vendors can obtain valuable marketing data on processor core types and hardware peripherals desired by embedded system designers during an evaluation phase.
[0112] Referring to FIG. 8, the IDE of the present invention may be used to form a simulation of an embedded system that may be used as a functional specification of the embedded system for the procurement of a good or service related to the embedded system. In a preferred embodiment, a virtual embedded system is created by a user, hosted on a web-based service, and used as an executable functional specification (i.e., as an interactive simulation that can be used to understand the function of the embedded system) for procuring a good or service related to the embedded system. In one embodiment, the executable functional specification may be downloaded. In one embodiment, a detailed design may be provided by the executable functional specification. In another embodiment, the level of hierarchy (e.g., the views of hardware, signals and pin symbols shown) are set at a part-level appropriate for a vendor. Additional information or annotation may also be included at the part-level. Test benches may also be configured to demonstrate the function at a part-level. In one embodiment, a virtual platform serves as a functional specification for procuring goods or services early in the development cycle before a working prototype is fabricated. In one embodiment, described below in more detail, the virtual platform is used as a basis of a request for quote.
[0113] A web-based service may also be used to facilitate the development of an embedded system project having one or more project members working in different geographical locations. In one embodiment, members of a user group have access privileges to a virtual platform hosted by the web-based service. Members of the user group may be granted privileges to run, copy, modify, annotate, or edit a version of the virtual platform. In one embodiment, a virtual embedded system (virtual platform) is created by a user group early in a development phase, e.g., shortly after the embedded system architecture is defined. Hardware engineers can then use the virtual platform as a basis for defining the hardware implementation while the software engineers can use the virtual platform to develop the software. Moreover, modification and design updates may be shared using a virtual prototype. In one embodiment, version control is included to permit members of a design team to create, edit, or modify a version of a virtual prototype. For example, a version of the virtual platform may be created to include a design update and then electronically communicated to other members of the design team (e.g., via a web-based service).
[0114] In one embodiment, the IDE of the present invention is used to provide a common, compatible design environment that facilitates the aggregation of IP components from different sources into a common service, preferably a web-based service. In particular, a preferred embodiment may include libraries containing virtual platforms and models of IP components from multiple vendors that are compatible with the IDE. This allows a user to select IP components of interest that they may add or, in the case of hardware models, modify for their own design. Additionally, libraries of reference hardware peripherals and sub-systems may also be included. Additionally, other libraries, such as a library of virtual test benches may be included. The aggregation of IP in a single design environment improves the efficiency of the design process by allowing embedded system designers to efficiently design a functional hardware description of an embedded system by picking and choosing IP components that are all compatible with the IDE. Moreover, the interaction of two or more IP components of a virtual prototype of embedded system may be rapidly evaluated in the IDE, which is typically not possible using conventional physical reference evaluation boards which are developed and manufactured for a single IP vendor.
[0115] Further details of various aspects of preferred embodiments of the present invention are described below in more detail in the following sections.
[0116] I. Preferred Finite State Machine Representation Of Hardware Components And Processes
[0117] The hardware partition of an embedded system typically includes at least one electronic hardware component (also known as a hardware "element"), such as a peripheral hardware component, forming a portion of the embedded system. Several hardware components may be included in the hardware partition. In accord with the present invention, the electronic components of the hardware partition are preferably modeled as concurrent, communicating Finite State Machines (FSMs). Referring to FIG. 17A, a conventional approach to designing a finite state machine description of hardware includes forming a state diagram and creating a state table of the state transitions. This model describes a system as a set of interacting machines, each having a local state. At an initialization time ( t=0), all FSMs start executing from their Start construct, being the explicit entry for an individual FSM. The behavior between the Start construct and the first State construct represents the initialization behavior of the FSM. At t=0, this behavior is executed for each FSM, until all FSMs reach their first State. The actual execution and progress of time start from that point on. In a preferred embodiment, the FSM models have process-level concurrency, inter-task communication, hierarchy, at arbitrary levels of nesting, and real-time support, by means of clocks and timers.
[0118] A preferred embodiment of the present invention includes a design language to rapidly create finite state representations of hardware components and processes in a visually intuitive format and which have a sufficiently low simulation overhead to permit a high-speed execution of software. In a preferred embodiment, the design language is an object-oriented design language with graphical attributes that facilitate quickly assembling a FSM model of system from pre-existing component models.
[0119] One aspect of the present invention is a design language, preferably an object-oriented design language, to form FSM models of hardware components and processes. FIGS. 19A and 19B are a table of preferred graphical objects (described by the inventors as "graphical constructs") for forming FSM models of hardware components and processes. As described below in more detail, the behavior of each object includes a graphical component associated with the shape of the object and a textual component input by a user. The graphical objects shown in FIG. 19 have shapes that are a subset of the graphical shapes of the Specification and Description Language (SDL), such as the SDL-92 language, and preferably combined with the ANSI C/C++ language to permit a user to define the behavior of a task construct. The Specification and Description Language (SDL) is a tool described by the international telecommunications union (ITU) for the specification and description of communication protocols in telecommunications systems. Conventional SDL provides a Graphic Representation (SDL/GR) and a textual Phrase Representation (SDL/PR), which are equivalent representations of the same semantics. In SDL a system is specified as a set of interconnected abstract machines that are extensions of the Finite State Machine (FSM). SDL permits a FSM model to be described as a directed graph of connected graphical objects (known as "symbols") expressing an extended finite state machine. The behavior of an SDL object is governed by its shape (which defines aspects of the function of the object) and textual semantics associated with the object (e.g., typically input inside of the graphical object). SDL includes a start object, state object, input object, state objects, text objects, and output objects. Details of SDL-92 are described in the book "Systems Engineering Using SDL-92," by Anders Olsen, Birger Moller-Pedeson, Rick Reed, and J. R. W. Smith, (Elsevier 1994), the contents of which are hereby incorporated by reference.
[0120] Conventional SDL, which was developed to describe communication protocols in telecommunications systems, has several drawbacks that limits its usefulness for designing hardware elements and processes for embedded systems. First, conventional SDL lacks language concepts for describing electronic hardware. Second conventional SDL includes semantics for described the behavior of complex communication systems that do not apply to the hardware design of conventional embedded systems. These complicated semantics increase the learning curve for conventional SDL. Third, conventional SDL has a high simulation overhead. The simulation overhead is about a factor of 100-to-1000 times larger than desired. The large simulation overhead of conventional SDL, results, in turn, in a corresponding reduction in the execution speed of a FSM simulation.
[0121] A preferred embodiment of the present invention includes a design language developed by the assignee of the present invention and known by the trade-name of "MAGIC-C". One aspect of MAGIC-C is the elimination of features of SDL required for telecommunications applications that are unnecessary for modeling hardware in order to reduce the simulation overhead. In accord with one embodiment of the present invention, the elimination of unnecessary aspects of SDL results in an object file of a hardware description having a low simulation overhead, e.g., a simulation overhead that is estimated by the inventors of the present application to be about a factor of 100-to-1000 lower than conventional SDL.
[0122] Many aspects of conventional SDL can be eliminated or modified to adapt SDL for describing the hardware of an embedded system. For example, conventional SDL processes include Inheritance and specialization of data types, state transitions and procedures (by means of virtual types, transitions and procedures). These constructs require a substantial simulation overhead, because they require dynamic lookup and checking. However, these are not very useful for a hardware simulation and may be eliminated. Similarly, conventional SDL includes polymorphism that is not very useful for modeling physical hardware and which thus may be eliminated to reduce simulation overhead. Conventional SDL also includes value returning (remote) procedures useful for software description but which impose a substantial simulation overhead because of the required stack parameter passing. Since these value returning features are not required for hardware modeling, they may be beneficially eliminated. Conventional SDL includes exported variables, called remote variables, which are not applicable to hardware modeling having encapsulated modules that communicate through signals and signal pins and thus this aspect of SDL may be beneficially eliminated. Conventional SDL includes features for dynamic process creation that requires extensive process tracking during simulation (e.g. in complex process tables), slowing down a simulation. However, for the case of hardware modeling, all the processes are known at compile-time such that dynamic process creation is not required. Conventional SDL, which was designed for telecommunication applications, also has a large simulation overhead because it uses virtual communication channels convey multiple signals that require dynamic routing to be performed during the simulation. However, virtual communication channels are not required for modeling hardware. Conventional SDL includes process identifiers (Pid) that are useful for referring to software processes (e.g. when executing on an operating-system), but which are unnecessary for hardware modeling. SDL includes provisions for spontaneous transition to model unreliable parts of a telecommunications system but which are unnecessary for a hardware simulation. Conventional SDL includes a prioritized signal-in construct require queue manipulation during simulation. However, this feature of SDL is unnecessary for a hardware simulation using a FIFO based queueing. Conventional SDL includes continuous signals and enabling conditions, which incur a very high simulation overhead because these signals need to be continuously updated and monitored for a triggering condition. These can be eliminated for a hardware simulation of an embedded system. Conventional SDL also includes services. A service differs from a process in that it does not execute concurrently with other services in the same process, but rather is implemented as part of the process'behavior. These can be eliminated for a hardware simulation. Conventional SDL includes features for creating parameterized types. In conventional SDL, signals, processes and services can be parameterized, making their actual type only known at run-time. This induces tremendous simulation overhead as it requires checking of the value and range of the parameters at run-time. In hardware modeling, all the types are known at compile-time making a parameterized type feature unnecessary. SDL also includes user-defined operators, which are not needed for hardware modeling.
[0123] In a preferred embodiment of a design language having graphical symbols adapted from SDL, the ANSI C language is used to specify the behavior of a task construct. In a preferred embodiment of the present invention, a task construct is restricted to a formal specification in ANSI C. ANSI C is widely used by embedded system designers and has a minimal learning curve for users, which is important for quickly composing new systems/models. Additionally, ANSI C has high-quality optimizing compilers/tools, which make the use of ANSI C to define task behavior compatible with a high-speed system simulation.
[0124] In a preferred embodiment of the present invention, the design language includes constructs for Symbols and symbol pins. The modeling of hardware modules is facilitated by the ability to create symbolic representation of hardware module that has representation of physical pins. One benefit of a Symbol is that Symbols can have multiple instances, supporting re-use of models and stimulating the quick development of emulators. These constructs are useful for encapsulating aspects of behavior so they can be re-used easily as library elements, stimulating the rapid composition of new hardware emulators. Also, it allows for intuitive modeling of connected hardware components in a hardware architecture, facilitating the rapidly composition of new emulators. Pins are used to connect symbol components with each other, or with the instruction-set simulator, to pass the memory transactions to the peripheral models.
[0125] In a preferred embodiment described below in more detail, a static compile-time parameter scheme is used for blocks, processes and symbols. A static compile time parameter reduces the simulation overhead, since parameters do not need to be calculated during the simulation.
[0126] FIG. 17B shows an example of a finite state machine using a sequence of graphical object (hereinafter "constructs") that has a graphical symbol portion and a textual portion. A plurality of graphical constructs is preferably included with the shape of the object defining a behavioral attribute or function of the object. The textual portion of the graphical construct also defines the attribute or function of the object. As shown in FIG. 17B, a graphical object may be linked to other graphical objects as a sequence of execution (e.g., a command flow of execution from top to bottom in analogy to a conventional flow chart). As shown in FIG. 18, in a preferred embodiment hardware elements or processes may be represented as communicating finite state machines using a broadcast signal communication model. FIG. 20 shows an example of a hardware counter implemented as a sequence of graphical objects.
[0127] As shown in the screen shots of FIGS. 21-24, toolbars having icons representing the symbols of the graphical constructs and steps in the creation of the finite state machine representation are preferably included to facilitate the rapid creation or modification of finite state models. This permits a menu-driven method of forming FSM representation in which a graphical construct is selected from a window; text, variables, or code are associated with the graphical object, and the graphical object is then connected (linked) to other graphical objects. Referring back to FIG. 10, a graphical database and a behavioral database is configured to convert the graphical object representation of the FSM into an equivalent semantic from which code can be generated to represent the hardware specification.
[0128] FIGS. 19A and 19B comprise a table showing a list of preferred graphical constructs for forming FSMs. A preferred graphical symbol and function of each construct is shown. A Declaration construct 1902 is a construct used to define local variables and signals. A Start construct 1904 defines a starting point of the finite state machine execution at the initialization time. A Task construct 1906 is an execution block containing at least one ANSI-C statement to be executed. A State construct 1908 defines a location where the finite state machine waits until a triggering signal is received. A Decision construct 191 0 directs a flow of execution based on the result of the expression evaluation inside the decision construct. A Signal-Out construct 1912 is used for sending of a communication signal. A Signal-In construct 1914 is used for receiving a communication signal. A Connector construct 1916 is used to connect the control between designs spanning over multiple pages. A Symbol construct 1920 is used to capture design hierarchy and structure. Pins are includes on the outline of the symbol construct 1920 for communication of signals. A Block construct 1922 captures design hierarchy and structure. A Block communicates through signals expressed by signal name. A Block can contain multiple processes. A Process construct 1924 acts as a leaf node in the design hierarchy describing a single finite state machine.
[0129] In a preferred implementation of the present invention, objects can be grouped into larger units. As shown in FIG. 28 this permits a top-level block diagram to be created which can be nested at different levels of hierarchy to show the functional aspects of the block at the desired level of detail. Referring to FIG. 29, this permits high-level diagrams of the embedded system to be formed with a sufficient level of detail and textual description to provide an intuitive understanding of the function of the system at a desired level of hierarchy. This introduction of hierarchy allows powerful abstraction and hiding of low-level details. In a preferred embodiment, hierarchy is created by defining Blocks, Processes, and Symbol constructs. A Block construct is a container for FSM Finite State Machines, and may be part of a larger block or process. Each Block may in turn consist of a Process or a substructure of Blocks. There is no specific behavior associated with a Block construct. Its behavior is the combined behavior of its underlying finite state machines. A Block construct may contain a Declaration construct, which in turn contain signal and variable definitions. FIG. 16
shows a Block construct containing a single Process construct, two Block constructs and a Declaration construct.
[0130] Hardware registers are declared as simulation variables in declaration blocks in a Magic-C design. Variables that need to be made visible in the test bench are are preferably implemented as C++ classes that implement specific Component Object Model (COM) interfaces that allow them to connect to test bench controls. They use operator overloading so they can be used in code as simple types. The operator overloading allows them to update the GUI each time their value changes. This allows them to be used in a very simple manner (like a primitive type), while giving complex functionality (updating the GUI).
[0131] The behavior of a Process is described as a FSM. When started, a Process executes its start transition and enters the first state. The reception of a signal triggers the transition from one state to the next state. In transit