U.S. patent application number 11/890018 was filed with the patent office on 2008-02-14 for systems and methods for modeling execution behavior.
This patent application is currently assigned to The MathWorks, Inc.. Invention is credited to Matthew Englehart.
Application Number | 20080040703 11/890018 |
Document ID | / |
Family ID | 37440994 |
Filed Date | 2008-02-14 |
United States Patent
Application |
20080040703 |
Kind Code |
A1 |
Englehart; Matthew |
February 14, 2008 |
Systems and methods for modeling execution behavior
Abstract
A mechanism in a block diagram environment allows the modeling
of an execution behavior of a block in a block diagram, where a
user selects the execution behavior from a plurality of functions
related to the block diagram and where the execution behavior of
the block is performed when at least one model variable associated
with the block satisfies a user-specified condition is disclosed.
States and other internal data in the designated block are
initialized upon the satisfaction of the user-specified condition.
The illustrative embodiment of the present invention also allows
the internal data to be reset upon the ending of the event, such as
the modeled introduction or withdrawal of power. The execution
behavior may be suspended and resumed multiple times during the
simulation in response to multiple occurrences of the specified
event. The present invention also allows for selected data to be
exempt from the reset process so that the selected data is
non-volatile.
Inventors: |
Englehart; Matthew; (Olmsted
Township, OH) |
Correspondence
Address: |
LAHIVE & COCKFIELD, LLP/THE MATHWORKS
One Post Office Square
Boston
MA
02109-2127
US
|
Assignee: |
The MathWorks, Inc.
Natick
MA
|
Family ID: |
37440994 |
Appl. No.: |
11/890018 |
Filed: |
August 3, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11170305 |
Jun 28, 2005 |
|
|
|
11890018 |
Aug 3, 2007 |
|
|
|
Current U.S.
Class: |
717/104 ;
717/107 |
Current CPC
Class: |
G06F 8/10 20130101; G06F
8/34 20130101 |
Class at
Publication: |
717/104 ;
717/107 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
Claims
1. A method for generating source code, the method comprising:
receiving a functional block diagram including at least one block,
the at least one block representing a component having at least one
first execution behavior that executes upon satisfaction of a first
user-specified condition; and generating source code that, when
compiled and executed by a controller, causes the controller to
simulate operation of the component.
2. The method according to claim 1, wherein generating source code
further comprises generating source code in a language executable
by a virtual machine.
3. The method according to claim 1, wherein receiving comprises
receiving a functional block diagram including at least one block,
the at least one block representing a hardware component.
4. The method according to claim 1, wherein receiving comprises
receiving a functional block diagram including at least one block,
the at least one block representing a component having at least one
first execution behavior that initializes an internal state of the
component.
5. The method according to claim 1, wherein receiving comprises
receiving a functional block diagram including at least one block,
the at least one block representing a component having at least one
first execution behavior that executes upon providing power to the
component.
6. The method according to claim 1, wherein receiving comprises
receiving a functional block diagram including at least one block,
the at least one block representing a component having at least one
first execution behavior that executes upon removing power from the
component.
7. The method according to claim 1, wherein receiving comprises
receiving a functional block diagram including at least one block,
the at least one block representing a component having at least one
first execution behavior that executes upon providing power to the
component multiple times.
8. The method according to claim 1, wherein receiving comprises
receiving a functional block diagram including at least one block,
the at least one block representing a component having a
sub-component, the sub-component having at least one second
execution behavior that executes upon satisfaction of a second
user-specified condition.
9. The method according to claim 8, wherein receiving a functional
block diagram including at least one block, the at least one block
representing a component having a sub-component, the sub-component
having at least one second execution behavior comprises receiving a
functional block diagram including at least one block, the at least
one block representing a component having a sub-component, the
sub-component having at least one second execution behavior that
executes upon provision of power to the sub-component.
10. The method according to claim 8, wherein receiving a functional
block diagram including at least one block, the at least one block
representing a component having a sub-component, the sub-component
having at least one second execution behavior comprises receiving a
functional block diagram including at least one block, the at least
one block representing a component having a sub-component, the
sub-component having at least one second execution behavior that
executes upon removal of power from the sub-component.
11. A computer-readable medium having computer-readable signals
stored thereon that define instructions that, as a result of being
executed by a computer, instruct the computer to perform the method
of claim 1.
12. A method for simulating component behavior, the method
comprising: presenting, to a user of a computer system, a plurality
of block diagram elements, the plurality including: at least one
element representing a component; at least one element representing
a first execution behavior of the at least one component; and an
least one element representing a first user-specified condition to
be satisfied prior to simulating the first execution behavior; and
receiving, from the user, a block diagram including: an element
representing an identified component; an element representing a
first execution behavior of the identified component; and an
element representing a first user-specified condition to be
satisfied prior to simulating the first execution behavior of the
identified component.
13. The method according to claim 12, wherein receiving, from the
user, the block diagram including the element representing the
identified component comprises receiving, from the user, a block
diagram including at least one element representing an identified
hardware component.
14. The method according to claim 12, wherein receiving, from the
user, the block diagram including the element representing the
first execution behavior of the identified component comprises
receiving, from the user, a block diagram including an element
representing the execution behavior that initializes an internal
state of the component.
15. The method according to claim 12, wherein receiving, from the
user, the block diagram including the element representing the
first user-specified condition to be satisfied prior to simulating
the first execution behavior of the identified component comprises
receiving, from the user, a block diagram including an element
representing provision of power to the component.
16. The method according to claim 12, wherein receiving, from the
user, the block diagram including the element representing the
first user-specified condition to be satisfied prior to simulating
the first execution behavior of the identified component comprises
receiving, from the user, a block diagram including an element
representing removal of power from the component.
17. The method according to claim 12, wherein receiving, from the
user, the block diagram including the element representing the
first user-specified condition to be satisfied prior to simulating
the first execution behavior of the identified component comprises
receiving, from the user, a block diagram including an element
representing provision of power to the component multiple
times.
18. The method according to claim 12, wherein presenting further
comprises presenting, to the user of the computer system, a
plurality of block diagram elements, the plurality including: at
least one element representing a sub-component; at least one
element representing a second execution behavior of the
sub-component; and at least one element representing a second
user-specified condition to be satisfied prior to simulating the
second execution behavior; and wherein receiving further comprises
receiving, from the user, a block diagram including: an element
representing an identified sub-component; an element representing
an identified second execution behavior; and an element
representing an identified second user-specified condition to be
satisfied prior to simulating the second execution behavior.
19. The method according to claim 18, wherein receiving, from the
user, the block diagram including the element representing the
second user-specified condition to be satisfied prior to simulating
the second execution behavior of the identified sub-component
comprises receiving, from the user, a block diagram including an
element representing provision of power to the sub-component.
20. The method according to claim 18, wherein receiving, from the
user, the block diagram including the element representing the
second user-specified condition to be satisfied prior to simulating
the second execution behavior of the identified sub-component
comprises receiving, from the user, a block diagram including an
element representing removal of power from the sub-component.
21. A computer-readable medium having computer-readable signals
stored thereon that define instructions that, as a result of being
executed by a computer, instruct the computer to perform the method
of claim 12.
Description
RELATED APPLICATIONS
[0001] The present application claims the benefit under 35 U.S.C.
.sctn. 120 and is a continuation of U.S. application Ser. No.
11/170,305, filed Jun. 28, 2005, now U.S. Publication No.
2006/0294505 A1, which is hereby incorporated herein by reference
in its entirety
FIELD OF THE INVENTION
[0002] The present invention relates to a system and method for
modeling behavior, and, in particular, for modeling execution
behavior of a component in a block diagram environment.
BACKGROUND
[0003] Various classes of graphical models describe computations
that can be performed on application specific computational
hardware, such as a computer, microcontroller, FPGA, and custom
hardware. Classes of such graphical models may include time-based
block diagrams such as those found within Simulink.RTM. from The
MathWorks, Inc. of Natick, Mass., state-based and flow diagrams
such as those found within Stateflow.RTM. from The MathWorks, Inc.
of Natick, Massachusetts, physical models such as those found
within SimMechanics from The MathWorks, Inc. of Natick,
Massachusetts, discrete-event based diagrams, data-flow diagrams,
and software diagrams such as those within the Unified Modeling
Language (UML). A common characteristic among these various forms
of graphical models is that they define semantics on how to
interpret or execute the model.
[0004] Block diagrams are graphical entities having an "executable
meaning" that are created within graphical modeling environments
for modeling a dynamic system, and generally comprise one or more
graphical objects. For example, a block diagram model of a dynamic
system is represented schematically as a first collection of
graphical objects, such as nodes, that are interconnected by
another set of graphical objects, generally illustrated as lines,
which represent logical connections between the first collection of
graphical objects. In most block diagramming paradigms, the nodes
are referred to as "blocks" and drawn using some form of geometric
object (e.g., circle, rectangle, etc.). The line segments are often
referred to as "signals." Signals correspond to the time-varying
quantities represented by each line connection and are assumed to
have values at each time instant. Each node may represent an
elemental dynamic system, and the relationships between signals and
state variables are defined by sets of equations represented by the
nodes. Inherent in the definition of the relationship between the
signals and the state variables is the notion of parameters, which
are the coefficients of the equations. These equations define a
relationship between the input signals, output signals, state, and
time, so that each line represents the input and/or output of an
associated elemental dynamic system. A line emanating at one node
and terminating at another signifies that the output of the first
node is an input to the second node. Each distinct input or output
on a node is referred to as a port. The source node of a signal
writes to the signal at a given time instant when its system
equations are solved. The destination nodes of this signal read
from the signal when their system equations are being solved. Those
skilled in the art will recognize that the term "nodes" does not
refer exclusively to elemental dynamic systems but may also include
other modeling elements that aid in readability and modularity of
block diagrams.
[0005] Dynamic systems are typically modeled as sets of
differential, difference, and/or algebraic equations. At any given
instant of time, these equations may be viewed as relationships
between the system's output response ("outputs"), the system's
input stimuli ("inputs") at that time, the current state of the
system, the system parameters, and time. The state of the system
may be thought of as a numerical representation of the dynamically
changing configuration of the system. For instance, in a physical
system modeling a simple pendulum, the state may be viewed as the
current position and velocity of the pendulum. Similarly, a
signal-processing system that filters a signal would maintain a set
of previous inputs as the state. The system parameters are the
numerical representation of the static (unchanging) configuration
of the system and may be viewed as constant coefficients in the
system's equations. For the pendulum example, a parameter is the
length of the pendulum; for the filter example, a parameter is the
values of the filter taps.
[0006] Unfortunately, conventional environments typically lack a
method for a user to select execution behavior to be performed, or
to specify a condition to be satisfied prior to the performance of
execution behavior, as opposed to evaluating the methods of the
block during the initialization of the model during the link stage.
Additionally, conventional simulation environments typically lack a
method for specifying that, when a power cycle is modeled, setup or
termination methods should execute upon introducing or withdrawing
the modeled power supply, respectively, or alternatively, that
there should be an exemption from any termination methods.
SUMMARY OF THE INVENTION
[0007] The illustrative embodiment of the present invention allows
the modeling of execution behavior of a block in a block diagram,
and evaluation of methods of designated subsystem blocks to be
controlled by events that are defined by conditions that are
functions of at least one model variable, such as the modeled
delivery of power to a subsystem block. Upon the occurrence of the
specified event, block setup methods may execute, including
initialization of states, other internal data in the designated
block, and associated hardware. The illustrative embodiment of the
present invention also allows the evaluation of termination methods
of designated subsystem blocks to be delayed until the occurrence
of a specified event, such as the modeled withdrawal of power from
a subsystem block. The setup or termination methods may be executed
multiple times during the simulation in response to multiple
occurrences of the specified event. The present invention also
allows for selected data to be exempt from the reset process when
the modeled power is withdrawn so that the selected data is
non-volatile. More generally, the present invention enables state
reset and initialization to be part of an initialization hierarchy
that is independent of the model decomposition hierarchy but that
could be directly related to it.
[0008] In one embodiment of the present invention, a method for
modeling execution behavior of a component in a block diagram
includes the step of providing a block in the block diagram. The
block has an execution behavior that is selected by a user and that
is performed when at least one model variable associated with the
block satisfies a user-specified condition, where the at least one
execution behavior is chosen from a plurality of functions related
to the block diagram. The method also includes the step of
performing the execution behavior of the block upon satisfaction of
the user-specified condition by the at least one model variable
associated with the block.
[0009] In another embodiment of the present invention, a method for
modeling execution behavior of a component in a block diagram
includes the step of providing a block in the block diagram. The
block has an execution behavior that is performed when a condition
on at least one model variable associated with the block is
satisfied, the behavior modeling power up and power down effects.
The method further includes the step of performing the execution
behavior of the block upon at least one model variable associated
with the block satisfying a condition.
[0010] In an embodiment of the present invention in a block diagram
environment, a system includes a block. The block has execution
behavior that is performed when a condition on at least one model
variable associated with the block is satisfied. The system also
includes a server. The server receives information about the block
and generates a block diagram responsive to the received
information.
[0011] In another embodiment of the present invention a method for
modeling execution behavior of a component in a block diagram
includes the step of providing a block in a block diagram, wherein
the block has at least one execution behavior that is performed
when a condition on at least one model variable associated with the
block is satisfied, modeling power being removed from the at least
model variable associated with the block. The method also includes
the step of performing at least one execution behavior of the block
upon a modeled removal of power from the at least one model
variable associated with the block through the satisfaction of a
condition by at least one model variable associated with the
block.
[0012] In another embodiment, in a block diagram environment, a
system includes a block having at least one execution behavior that
is performed when a condition on at least one model variable
associated with the block is satisfied, modeling withdrawing power
from the block. The system also includes a server that receives
information about the block and generates a block diagram
responsive to the received information.
[0013] In an embodiment of the present invention, a method of
modeling a block with a nonvolatile state includes the step of
providing a block representing the block with the nonvolatile
state. The method also includes the steps of storing an internal
state of the block and suspending the execution of the block upon a
modeled removal of power from the block. The method additionally
includes the step of preserving the internal state of the block
after suspension of the execution of the block. The method
additionally includes the steps of resuming execution of the block
upon a subsequent modeled introduction of power to the block, and
subsequently using the preserved internal state to initialize an
internal state of the block.
[0014] In another embodiment of the present invention in a block
diagram environment, a system for modeling a nonvolatile block
includes a server. The server stores an internal state of a modeled
nonvolatile component, and preserves the internal state of the
component after suspending modeling of the nonvolatile component.
The server also uses the preserved internal state to initialize an
internal state of the block.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] These and other aspects of this invention will be readily
apparent from the detailed description below and the appended
drawings, which are meant to illustrate and not to limit the
invention, and in which:
[0016] FIG. 1A is a flow diagram depicting one embodiment of steps
taken in a method for modeling execution behavior of a component in
a block diagram;
[0017] FIG. 1B is a block diagram depicting one embodiment of a
block diagram environment including a subsystem;
[0018] FIG. 1C is a block diagram depicting one embodiment of an
apparatus enabling a user to select execution behavior for a
block;
[0019] FIG. 1D is a block diagram depicting, in detail, an
illustrative example of a block provided in a block diagram
environment;
[0020] FIG. 2 is a flow diagram depicting one embodiment of the
steps taken to model power up behavior of a block in a block
diagram environment;
[0021] FIG. 3 is a flow diagram depicting one embodiment of the
steps taken to model power down behavior of a block in a block
diagram environment;
[0022] FIG. 4 is a block diagram depicting one embodiment of a
system generating a block diagram and simulating power up behavior
of a block in the block diagram;
[0023] FIG. 5 is a block diagram of an embodiment of a system
generating a block diagram and simulating power down behavior of a
block in the block diagram;
[0024] FIG. 6 is a flow diagram depicting one embodiment of the
steps taken to perform power up behavior of a block more than one
time in a simulation;
[0025] FIG. 7 is a flow diagram depicting one embodiment of the
steps taken to perform power down behavior of a block more than one
time in a simulation;
[0026] FIG. 8 is a block diagram depicting, in detail, one
embodiment of a block provided by the present invention in a block
diagram;
[0027] FIG. 9 is a block diagram depicting one embodiment of a
system containing a power up and power down subsystem;
[0028] FIG. 10 is a code fragment depicting one embodiment of code
generated for a system containing power up and power down
subsystems;
[0029] FIG. 11 is a block diagram depicting in greater detail one
embodiment of a system with two subsystems;
[0030] FIG. 12 depicts one embodiment of code for an accelerated
simulation of the system 1100;
[0031] FIG. 13 is a block diagram is an illustrative enable port
dialog;
[0032] FIG. 14 is a flow diagram depicting one embodiment of the
steps taken to model a nonvolatile block in a block diagram
environment;
[0033] FIG. 15 is a block diagram depicting an illustrative example
of a graphical user interface on a server collecting
information;
[0034] FIG. 16 is a block diagram depicting, in greater detail, one
embodiment of the steps taken to model a nonvolatile variable in a
block diagram environment such as a Stateflow chart;
[0035] FIG. 17 is a block diagram depicting one embodiment of a
variable with a nonvolatile state in an embedded MATLAB block
diagram environment;
[0036] FIG. 18 depicts one embodiment of code generated for an
embedded MATLAB environment in which a variable has a nonvolatile
value;
[0037] FIG. 19 is a block diagram depicting, in greater detail, one
embodiment of the steps taken to model a nonvolatile variable in a
block diagram environment such as a Stateflow chart with a history
junction;
[0038] FIG. 20 is a block diagram depicting one embodiment of a
system containing blocks in a block diagram environment referencing
both volatile and nonvolatile memory;
[0039] FIG. 21 depicts one embodiment of generated code for
simulation of a system in the present invention;
[0040] FIG. 22 depicts one embodiment of code used to detect
transitions from a powered down state to a powered up state;
and
[0041] FIG. 23 depicts one embodiment of code generated independent
of any software environment.
DETAILED DESCRIPTION OF THE INVENTION
[0042] The illustrative embodiment of the present invention
provides support for modeling execution behavior of a component in
a block diagram environment. When an execution environment is
notified that at least one model variable associated with a block
satisfies a user-specified condition, execution behavior specific
to the satisfaction of that the user-specified condition is
performed. For example, when a simulation environment is notified
that a power cycle has ended, behavior specific to the termination
of a power cycle is performed. The condition may repeatedly
transition between true and false within a particular simulation.
The performance of a particular execution behavior is triggered by
the satisfaction of a user-specified condition involving at least
one model variable associated with a block, and not by the
beginning or ending of a particular simulation. Thus, in contrast
to conventional block diagram environments, the illustrative
embodiment of the present invention provides a way to exempt
specified blocks from the nominal evaluation of the methods for the
block and enable a user to specify when execution behavior should
be performed. Furthermore, compile and link stage evaluations may
also be performed an arbitrary number of times.
[0043] The illustrative embodiment of the present invention
provides a graphical programming or modeling environment in which a
graphical program or model is simulated/executed or code is
generated for the model. In the description of the illustrative
embodiment, the simulation of the graphical program/model is also
referred to as the execution of the program/model.
[0044] The illustrative embodiment will be described below solely
for illustrative purposes relative to a time-based block diagram
environment. Although the illustrative embodiment will be described
relative to the time-based block diagram environment, one of skill
in the art will appreciate that the present invention may apply to
other graphical programming/modeling environments, including
state-based and flow diagram environments, data flow diagram
environments and Unified Modeling Language (UML) environments, as
long as the graphical model has some notion of semantics that
allows it to be transformed into an executable for a computer
processor/microcontroller or directly synthesized in
application-specific hardware.
[0045] The illustrative embodiment will be described below relative
to a Simulink.RTM. model, a time-based block diagram found in
Simulink.RTM. from The MathWorks, Inc. of Natick, Mass.
Nevertheless, those of skill in the art will appreciate that the
present invention may be practiced relative to models implemented
in other graphical modeling environments, including but not limited
to LabVIEW from National Instruments Corporation of Austin, Tex.,
and Rational Rose from IBM of White Plains, N.Y.
[0046] In some embodiments, the user-specified conditions model the
introduction and removal of power from a block. More generally, the
present invention enables state reset and initialization to be part
of a hierarchy that is independent of the model decomposition
hierarchy but that could be directly related to it.
[0047] In some embodiments, a block diagram execution engine
contributes to the modeling software task of enabling the
computation and tracing of a dynamic system's outputs from its
block diagram model. An execution engine carries out the task of
compiling and linking the block diagram to produce an "in-memory
executable" version of the model that is used for generating code
and/or simulating or linearizing a block diagram model. Note that
execution of the block-diagram is also referred to as simulation.
The compile stage involves checking the integrity and validity of
the block interconnections in the block diagram. In this stage, the
engine also sorts the blocks in the block diagram into hierarchical
lists that are used when creating the block method execution lists.
In the link stage, the execution engine uses the result of the
compiled stage to allocate memory needed for the execution of the
various components of the block diagram. The linking stage also
produces block method execution lists, which are used by the
simulation or linearization of the block diagram. Included within
the link stage is the initialization of the model which consists of
evaluating "setup" methods (e.g. block start, initialize, enable,
and constant output methods). The block method execution lists are
generated because the simulation and/or linearization of a model
must execute block methods by type (not by block) when they have a
sample hit.
[0048] After linking has been performed, the execution engine may
generate code. In this stage, the execution engine may choose to
translate the block diagram model (or portions of it) into either
software modules or hardware descriptions (broadly termed code). If
this stage is performed, then the stages that follow use the
generated code during the execution of the block diagram. If this
stage is skipped completely, then the execution engine uses an
interpretive mode of execution for the block diagram. In some
cases, the user may not proceed further with the execution of the
block diagram because they would like to deploy the code outside
the confines of the block diagram software. Upon reaching the
simulation stage, the execution engine uses a simulation loop to
execute block methods.
[0049] For illustrative purposes, we discuss Simulink and Stateflow
examples but one skilled in the art will appreciate that the
present invention may be used with other graphical modeling,
simulation and programming environments. Simulink is one example of
an environment that provides users with the ability to model
subsystems in a block diagram environment. Two options previously
unavailable to users but available in the present invention are the
ability to model activity associated with the satisfaction of user
selected criteria on model variables. In one embodiment, this
provides the ability to model activity associated with simulating
an introduction of power and the ability to model activity
associated with simulating a removal of power.
[0050] The illustrative embodiment of the present invention
concerns graphical modeling environments, such as block diagram
modeling environments, provided on a computational device. Such
block diagrams may be representations of real-world systems that
contain nodes (called blocks) interconnected by arcs (called
lines). The blocks are functional entities that perform operations.
The lines represent data (called signals) being communicated
between the various blocks. One of skill in the art will appreciate
that the block diagrams are an illustrative graphical modeling
environment and the present invention may apply to other types of
graphical modeling and programming environments.
[0051] FIG. 1A depicts a flow diagram of one embodiment of steps
taken in a method for modeling execution behavior of a component in
a block diagram. In brief overview, a block is provided (step 120)
and a model variable associated with the block is provided (step
122). A user specifies a condition to be satisfied prior to
execution behavior of the block being performed (step 124). At
least one execution behavior of the block is performed upon
satisfaction of the user-specified condition involving at least one
model variable associated with the block (step 126).
[0052] A block is provided (step 120), the block having at least
one execution behavior selected by a user. A model variable is also
provided (step 122). In one embodiment, a variable is a Simulink
signal. The model variable may be associated with the block.
[0053] The block has at least one execution behavior chosen from a
plurality of functions related to the block diagram. In some
embodiments, a plurality of execution behaviors are chosen by the
user. The functions performed by the execution behaviors may be
evaluated during execution of the model. In some embodiments, the
execution behavior performs evaluation of model characteristics. In
other embodiments, the execution behavior performs an evaluation of
model functionality. In still other embodiments, the execution
behavior performs a function that is conventionally performed prior
to the execution phase. In one embodiment, the execution behavior
may execute during compilation, which includes, without limitation,
sample time propagation, data type propagation, constant
propagation, algebraic loop removal, or dead path elimination. In
another embodiment, the execution behavior may execute during
linking, which includes task list compilation. In still another
embodiment, the execution behavior may include methods such as
optimization methods, analysis methods, and synthesis methods. In
yet another embodiment, the execution behavior may include
functions that are associated with block execution such as block
output functions, update functions, zero crossing functions,
derivative functions, initialization functions, enable functions,
termination functions, disable functions, and start functions.
[0054] A user specifies a condition to be satisfied prior to
execution behavior of the block being performed (step 124). A user
may specify a condition when selecting the at least one execution
behavior to be performed. In some embodiments, the user specifies a
trigger and the execution behavior of the block is performed upon
the occurrence of the trigger. In other embodiments, the user
specifies a state and the execution behavior of the block is
performed when the state is active. In yet other embodiments, the
user specifies a state and the execution behavior of the block is
performed when the state is inactive. Simulating an introduction of
power to a model variable or a removal of power from the model
variable are two examples of conditions that a user may specify.
The execution behavior of the block is performed when at least one
model variable associated with the block satisfies a user-specified
condition (step 126).
[0055] FIG. 1B shows a block diagram 130 with a subsystem 132,
labeled `Method Select Subsystem` in this embodiment. The subsystem
132 contains two Method Selector input ports marked M that take one
or more input signals based on which the user can select methods to
be executed.
[0056] FIG. 1C is block diagram depicting one embodiment of an
apparatus enabling a user to select execution behavior for a block.
FIG. 1C shows a dialog presented to the user. The user may select
methods from the list 142 as execution behavior of the block 132.
The methods may be executed when the execution behavior of the
block is performed. The list 142 may be context dependent. For
example, in some embodiments the list 142 may account for the
solver type that is used for execution. The list 143 displays to
the user the methods that the user has already selected as
execution behavior for the block. From the list 142, one or more
sets of methods can be composed to form execution behavior of a
block. In FIG. 1C, three such sets are present, as illustrated by
the list 144. The current three sets are named `Power Up`, `Power
Down`, and `Dynamic Optimization`. Users may add or delete sets
from the list 144.
[0057] FIG. 1C shows one embodiment where the list 144 includes a
presently selected set of methods named `Dynamic Optimization`. The
presently selected set of methods contains the three methods listed
in the right-hand list box, `blkInitialize`, `blkEnable`, and
`blkDeadPathReduction`. When an input signal to the corresponding
Model Select port satisfies a user-defined criterion, the methods
are executed in sequence, starting at the top of the list. In this
embodiment, the user criterion can be selected as a combination of
a rising-edge trigger, a falling-edge trigger, availability of a
value of 1, and the non-availability of a value of 1. These options
are shown as a set of checkboxes 145.
[0058] The following is an example of designing a power up power
down subsystem with the present invention, meant to illustrate and
not limit the invention. The user selects a Method Select Subsystem
with one Method Selector port. This port then has three method sets
associated with it: (1) a method set to be executed when the input
signal to the Method Selector port has a rising edge which includes
the blkStart, blkInitialize, and blkEnable methods, (2) a method
set to be executed when the input signal to the Method Selector
port has a falling edge which includes the blkTerminate and
blkDisable methods, and (3) a method set to be executed when the
input signal to the Model Selector port is 1 (high) which includes
the blkOutput method.
[0059] The Method Selector allows selection of any method as
employed by model processing and execution. This includes model
compilation methods such as, for example, mdlPropagateSampleTimes,
mdlPropagateConstants, and mdlSort, as well as model linking
methods such as mdlInitializeTaskLists and mdlAllocateMemory, but
also model execution methods such as mdlJacobian, mdlOutput,
mdlZeroCrossings, and mdlUpdate. This furthermore includes block
specific methods such as, for example, blkPropagateConstants,
blkInitializeTaskLists, blkStart, and blkDerivatives.
[0060] FIG. 1D is a block diagram depicting an illustrative example
of how a block diagram provided by the present invention might
appear in a block diagram environment 100 where the user-specified
condition is satisfied when power is introduced or removed from a
component in the block diagram, including a Stateflow block 102
residing in a Simulink diagram and representing a Stateflow
diagram, a power state 104, a power up/power down subsystem 112, a
power port 106, an out port 108, and in port 110. FIG. 1D is a
block diagram model of a dynamic system that may be simulated and
from which code may be generated. The power up/power down subsystem
112 is an illustrative example of the block provided by one
embodiment of the present invention. In some embodiments, the power
up/power down subsystem 112 is a method select subsystem. The power
up/power down subsystem 112 is active only when enabled by a
control signal, in this case, when enabled by the power in port
110. This example is meant to illustrate and not to limit the
invention. In other embodiments, the symbols used vary from those
depicted. In still other embodiments, the graphical user interface
of the windowing system would differ from the graphical user
interface depicted.
[0061] The Stateflow diagram 102 includes a power state 104. In one
embodiment, the Stateflow diagram 102 is a finite state machine
with two states, power up and power down. The power up/power down
subsystem 112 includes a power port 106, an out port 108, and an in
port 110. When the power state 104 is power up, the Stateflow
diagram 102 notifies the power up/power down subsystem 112. In some
embodiments, the Stateflow diagram 102 notifies the power up/power
down subsystem 112 over the power port 106. When the power port 106
is notified that the power state 104 is power up, in some
embodiments, this triggers the performance of power up behavior by
the power up/power down subsystem 112. When the power port 106 is
notified that the power state 104 is power down, in some
embodiments, power up/power down subsystem 112 performs the power
down behavior.
[0062] Thus, the power state 104 represents state information
indicating whether the power is "on" or "off." The state
information is communicated to the power up/power down subsystem
112 or another block that is responsive to the state. At state
transitions, the power up/power down subsystem 112 or other block
performs the appropriate behavior in response to the state
transition. For the more general case, a block provides power cycle
state information that is received by a block that responds to the
state information.
[0063] FIG. 2 depicts the steps taken to simulate at least one
execution behavior of a block in a block diagram environment in an
illustrative embodiment. Initially, a block is provided (step 202).
The block may be associated with at least one execution behavior.
The at least one execution behavior of the block is performed upon
an introduction of power to the block via the at least one model
variable associated with the block (step 204).
[0064] In some embodiments, the at least one execution behavior
comprises initializing an internal state of the block. As noted
above, blocks may have state information regarding the current
state of the block. It is this state information that may be
initialized for the block to begin to perform its designated role
in a model. The at least one execution behavior may also include
initiating execution upon each simulated introduction of power to
the block. In some embodiments, the at least one execution behavior
comprises initializing one or more hardware components associated
with the block. For embodiments where the at least one execution
behavior is required to be performed not at the beginning of
simulation (as in conventional systems) but rather during the
simulation, at the simulated introduction of power to the at least
one model variable associated with the block, the block may be
configured to enable the at least one execution behavior to be
performed at a time other than the initialization of the
simulation. In some cases, the at least one execution behavior of
the block is performed for more than one simulated introduction of
power to the block via at least one model variable associated with
the block. Over the course of a single simulation, there may be
more than one simulated introduction of power to the block via at
least one model variable associated with the block.
[0065] FIG. 3 depicts steps taken to model execution behavior of a
block in a block diagram in an embodiment of the present invention.
A block is provided that is associated with at least one model
variable and that is responsive to the simulated removal of power
(step 302). The execution behavior of the block is performed upon a
simulated removal of power from the block via at least one model
variable associated with the block (step 304). In some instances,
the execution behavior of the block is performed for more than one
simulated removal of power from the block via at least one model
variable associated with the block. In some embodiments, the at
least one execution behavior may include resetting an internal
state of the block and/or terminating simulation upon each
simulated removal of power from the at least one model variable
associated with the block. In some embodiments, the at least one
execution behavior also includes initializing one or more hardware
components associated with the block.
[0066] Referring now to FIG. 4, a block diagram depicts one
embodiment of a system for generating a block diagram and modeling
at least one execution behavior of a block in the block diagram.
The system includes a server 402, received information 404, a block
diagram environment 406, a block 408, and a client 410. In brief
overview, the server 402, receiving information 404 from client 410
about the block 408, generates a block diagram in a block diagram
environment 406, responsive to the received information 404.
[0067] In some embodiments, the server 402 generates the block
diagram 406 with block 408 responsive to the information 404. In
some of these embodiments, the received information 404 comprises a
client 410 request for the server 402 to generate a block 408
capable of simulating power up behavior or power down behavior. In
others of these embodiments, the received information 404 comprises
a client request that the block 408 be capable of simulating both
power up and power down behavior.
[0068] In some embodiments, the server 402 resides on a network in
a client-server system. In some of these embodiments, the server
receives information 404 over the network. In some embodiments, the
server receives information 404 from the client 410 on the
client-server system.
[0069] In FIG. 5, a block diagram depicts one embodiment of a
system generating a block diagram and modeling execution behavior
of a block in the block diagram. The system includes a computing
system 502, information 504, a block diagram environment 506, and a
block 508. In brief overview, the computing system 502, containing
information 504 about the block 508, generates a block diagram in a
block diagram environment 506, responsive to the information 504.
In the embodiment depicted in FIG. 5, there is only a single
computing system and not a client-server networked system.
[0070] In some embodiments, the computing system 502 generates the
block diagram 506 with block 508 responsive to the information 504.
The received information 504 may be a user request for the
computing system 502 to generate a block 508 capable of simulating
power up behavior or power down behavior. In others of these
embodiments, the user requests that the block 508 be capable of
simulating both power up and power down behavior.
[0071] Although only one computing system 502, server 402, block
408, and block 508 are depicted in the embodiment shown in FIG. 4
and FIG. 5, it should be understood that the system might provide
multiple ones of any or each of those components. Additionally, a
block 508 or block 408 might have, in some embodiments, both power
up and power down behavior within a single block.
[0072] Referring now to FIG. 6, a flow diagram depicts the steps
taken to perform at least one execution behavior of a block more
than one time in a simulation. Power may be provided to and removed
from a block via at least one model variable associated with the
block more than one time, in some embodiments. The block has at
least one execution behavior, which is performed at each simulated
introduction of power to the block via at least one model variable
associated with the block. In some embodiments, power is provided
to the block via at least one model variable associated with a
block a first time (step 602). The at least one execution behavior
of the block is then performed (step 604). A removal of power from
the block via at least one model variable associated with the block
occurs (step 606), followed at a later point in time by a second
provision of power to the block via at least one model variable
associated with the block (step 608). At the second provision of
power to the block via at least one model variable associated with
the block, the at least one execution behavior of the block is
performed a second time (step 610). In these embodiments, the at
least one execution behavior would be performed each time that
power is provided to the block via at least one model variable
associated with the block.
[0073] In FIG. 7, a flow diagram depicts the steps taken to perform
power up and power down behavior of a block more than one time in a
simulation. Power may be provided to and removed from the block via
at least one model variable associated with the block more than one
time, in some embodiments. The block has power down behavior, which
is performed at each removal of power from the block via at least
one model variable associated with the block. In some embodiments,
power is removed from the block via at least one model variable
associated with the block a first time (step 702). The power down
behavior of the block is then performed (step 704). An introduction
of power to the block via at least one model variable associated
with the block occurs (step 706), followed at a later point in time
by a second removal of power from the block via at least one model
variable associated with the block (step 708). At the second
removal of power from the block via at least one model variable
associated with the block, the power down behavior of the block is
performed a second time (step 710). In these embodiments, the power
down behavior would be performed each time that power is provided
to the block via at least one model variable associated with the
block.
[0074] In FIG. 8, a block diagram depicts, in detail, one
embodiment of a block 802 in a block diagram 800. In some
embodiments, the block 802 comprises one or more sub-components 804
and 808. In some embodiments, a sub-component 804 or 808 may have
more than one behavior. For example, sub-component 808 could, in
some embodiments, have behavior 810 and behavior 812, and each
behavior could be different. Behavior 810 could be power up
behavior and behavior 812 could be power down behavior.
[0075] For each block 802 in a block diagram 800, and for each
sub-component 804 or 808, state control is intrinsic and
independent. That is, each sub-component 804 or 808 within a block
802 and each block 802 within a block diagram 800 retains control
over its own behavior. State reset and initialization for each
block 802, and for each sub-component 804 within the block 802, may
be part of an initialization hierarchy that is independent of the
model decomposition hierarchy but that could be directly related to
it.
[0076] The power behavior of each sub-component is performed when
the power is provided to or removed from the sub-component. The
power behavior of each sub-component in these embodiments may be
different from the power behavior of other sub-components within
the same block 802, and from the power up behavior of the block
802. Additionally, in some of these embodiments, power may be
supplied to or removed from each sub-component at a different time
from when power is provided to or removed from other sub-components
within the same block 802, and from when power is provided to or
removed from the block 802.
[0077] In some embodiments, a block 802 may contain one or more
sub-components with nonvolatile states. For example, within block
802, a particular sub-component 804 may have behavior 808
designating an internal state to be non-volatile.
[0078] FIG. 9 shows a block diagram for an embodiment of a system
containing a power up and power down subsystem. As discussed above
with regards to FIG. 8, a block diagram environment may comprise
blocks 802 having state control intrinsic to the block 802 and
independent from any other block. Similarly, in some embodiments, a
system within a block diagram 900 may have multiple subsystems 902
and 904, each of which have independent execution behavior.
[0079] Referring now to FIG. 9 and in greater detail, a subsystem
902 may reside within a block diagram 900 and may model one or more
blocks 802. The present invention provides a new functionality to
previously existing subsystems in that the present invention
enables a subsystem to be a power up subsystem or a power down
subsystem. The subsystem 902, in one embodiment, is a power up
system. In this embodiment, subsystem 902 executes power up
behavior on the first time-step after the block diagram 900 powers
up. The subsystem 904 is a power down system executing power down
behavior as the block diagram 900 powers down. In environments
using Simulink, a "Ports and Subsystems" library of subsystems may
be modified to include new blocks supporting this functionality.
These modified blocks may include a power up/power down port block
and a power up/power down subsystem, comprising a power up/power
down port block and an in-port connected to an out-port.
[0080] The parent block diagram 900 depicted in FIG. 9 includes a
power up subsystem 902 and a power down subsystem 904. Both power
up subsystem 902 and power down subsystem 904 accept inputs, and
power up subsystem 902 generates output, which is sent via the
product element 906, to the power down subsystem 904. As depicted
in FIG. 9, the power up subsystem 902 comprises a data store read
element 908, a product element 906, and a lookup table 912. These
elements interact with input to generate an output which the power
up subsystem sends to other elements and subsystems in the parent
block diagram 900. Similarly, as depicted in FIG. 9, the power down
subsystem 904 comprises a lookup table 914 and a data store write
element 916 each interact with each other and with an input to the
power down subsystem 904. One skilled in the art will appreciate
the elements within each subsystem may vary from those depicted in
FIG. 9.
[0081] Using a subsystem 902 or subsystem 904 improves code
efficiency by providing a mechanism for executing blocks at a
restricted set of times--the times when the parent block diagram
900 is powered up or powered down. Using the subsystem provides a
mechanism for specifying blocks that execute at power up or at
power down only. Additionally, using a subsystem 902 or subsystem
904 provides a new semantic whereby blocks can be executed during
simulated system shutdown.
[0082] A sub-system in the block diagram 900 may have a property
enabling persistence of values contained in the sub-system to
persist throughout a simulated non-operational cycle. Thus, the
present invention enables prevention of loss of a value at power
down or power up of the sub-system 902 or 904 and at power down or
power up of the parent block diagram 900. The power up subsystem
902 may be persistent to allow retainment of values contained
within the power up subsystem 902 throughout a non-operational
cycle. The power down subsystem 904 may also be persistent to
enable retainment of values contained within the power down
subsystem 904 throughout the non-operational cycle.
[0083] Referring now to FIG. 10, a code fragment depicts one
embodiment of code generated for a block diagram 900 containing a
power up subsystem 902 and a power down subsystem 904. Line 5
depicts one embodiment in which the execution of the code for the
power up subsystem 902 occurs when the block diagram 900 is
powering up. Line 16 depicts another embodiment in which the
execution of the code for the power down subsystem occurs when
block diagram 900 is powering down.
[0084] Referring now to FIG. 11, a block diagram depicts in greater
detail one embodiment of a system with two subsystems. In one
embodiment, the software environment 1100, includes software 1102.
Software 1102 includes a reset subsystem 1104, and a hold subsystem
1108. In one embodiment, state reset and initialization are part of
a hierarchy that is independent of the model decomposition
hierarchy but that could be directly related to it.
[0085] In one embodiment, the reset subsystem 1104 is configured to
reset the values of its states when transitioning from disabled to
enabled (such as when the signal entering its control port on the
top of the block becomes positive). In another embodiment, the hold
subsystem 1108 is configured to hold the values of its states when
transitioning from disabled to enabled (when the signal entering
its control port on the top of the block becomes positive).
[0086] As depicted in FIG. 11, the reset subsystem 1104 comprises a
volatile delay element 1105 and a nonvolatile delay element 1106.
These elements interact with input to generate an output, which the
reset subsystem 1104 sends to other elements and the hold subsystem
1108 in the software 1102. Similarly, as depicted in FIG. 11, the
hold subsystem 1108 comprises a volatile delay element 1110 and a
nonvolatile delay element 1112 and each of these elements interact
with input to the hold subsystem 1108 and generate output. One
skilled in the art will appreciate the elements within each
subsystem may vary from those depicted in FIG. 11.
[0087] One embodiment of code for an accelerated simulation of the
software 1102 is shown in FIG. 12. In this embodiment, at Time 0
nonvolatile states have their values initialized (lines 2-4),
independent of where they are used in the hierarchy. When the
software 1102 transitions from powered down to powered up, the
volatile states of the system are initialized (lines 13-14),
regardless of where they are used in the hierarchy. In contrast,
when the hold subsystem 1108 transitions from disabled to enabled,
only the volatile state of "Volatile Delay1" initializes (line 23)
because it resides within that portion of the model hierarchy.
Finally, when the software 1102 powers down, the volatile states
are reset (lines 54-55), once more regardless of where they reside
in the hierarchy.
[0088] FIG. 13 shows an example of a dialog for the enable port of
a power up/power down subsystem block in an illustrative embodiment
of the present invention. The parameters portion of the dialog
includes a check box to designate whether the subsystem will be a
power up/power down subsystem. Power up/power down subsystems are
an illustrative case of a system block or subsystem that
incorporates the principles of the present invention. The present
invention is not limited to the power up/power down subsystem
case.
[0089] In some embodiments, prior to providing the block, user
input is received about the block. In some of these embodiments,
the user input may comprise a request to model the power up
behavior of the block. In others of these embodiments, the
determination to model the block is based upon evaluating the
received user input. In other embodiments, the user input may
comprise a request to simulate the power up behavior of the block.
In some of these embodiments, the determination to simulate the
block is based upon evaluating the received user input.
[0090] In some embodiments, the graphical user interface collects
information using checkmark boxes. In other embodiments, the
graphical user interface collects information using objects other
than checkmark boxes. This example is meant to illustrate and not
to limit the invention.
[0091] The illustrative embodiment of the present invention enables
the use of a "non-volatile" property with a powered subsystem
block. The property allows an instance of data to be specified as
non-volatile. The designation of the instance of data as
"non-volatile" results in the value of the instance of data being
retained by the powered subsystem when the powered subsystem is
disabled or re-enabled. The initial condition of the instance of
data is applied only a single time, such as when the powered
subsystem first enables.
[0092] Referring now to FIG. 14, a flow diagram depicts one
embodiment of the steps taken to model a block with a nonvolatile
state in a block diagram environment. In brief overview, a block
representing a block with a nonvolatile state is provided (step
1402). An internal nonvolatile state of the block is stored (step
1404). Modeling of the block is suspended upon a removal of power
from the simulation environment (step 1406). The internal
nonvolatile state of the block is preserved upon suspension of the
modeling (step 1408). Modeling of the block is resumed upon an
introduction of power to the simulation environment (step 1410).
The preserved internal nonvolatile state of the block is used to
initialize an internal state of the block upon initiation of
modeling of the block (step 1412).
[0093] Referring to FIG. 14, and in more detail, in one embodiment
a determination is made to model a block with a nonvolatile state
in a block diagram environment for more than one cycle of
introducing and removing power from the block. In some embodiments,
information about the block with a nonvolatile state is received.
In some of these embodiments, the determination to model a block
with a nonvolatile state is made responsive to the received
information.
[0094] An internal nonvolatile state of the block is stored (step
1404). In some embodiments, more than one internal nonvolatile
state of the block may be stored. In other embodiments, there are
volatile and nonvolatile states within the same block. In still
other embodiments, the received information identifies the internal
nonvolatile state or states to be stored.
[0095] In one embodiment, modeling of the block is suspended upon a
removal of power from the simulation environment (step 1406) and
the internal nonvolatile state of the block is preserved upon
suspension of the modeling (step 1408). In this embodiment, the
preservation of an internal nonvolatile state or states of the
block after suspension of the modeling and usability of the
preserved internal nonvolatile state or states are the
characteristics of the state or states that make it nonvolatile.
The internal nonvolatile state may be stored on a server, in some
embodiments. In other embodiments, the internal nonvolatile state
may be stored on a data store.
[0096] Modeling of the block is resumed upon an introduction of
power to the simulation environment (step 1410). In some
embodiments, modeling of the block includes performing power up
behavior of the block. The power up behavior of the block may
include initializing internal states of the block. In one
embodiment, the preserved internal nonvolatile state of the block
is used to initialize the same internal nonvolatile state of the
block upon initiation of modeling of the block (step 1412). In this
embodiment, the internal state of the block is the same before
termination of the modeling and after initialization of modeling of
the block.
[0097] FIG. 15 is a block diagram depicting an illustrative example
of a graphical user interface on server 402 collecting information
404. In one embodiment of the server 402, a graphical user
interface collects information 404. In some embodiments, the
graphical user interface collects information 404 using checkmark
boxes. In other embodiments, the graphical user interface collects
information 404 using objects other than checkmark boxes. This
example is meant to illustrate and not to limit the invention.
[0098] Referring now to FIG. 16, a block diagram depicts, in
greater detail, one embodiment of the steps taken to model a
nonvolatile variable in a block diagram environment such as a
Stateflow chart. In brief overview, a block diagram environment
1600 includes a chart 1602, data input 1604, data output 1606, and
variable 1608. In some embodiments, Stateflow charts enable the
graphical representation of hierarchical and parallel states and
the event-driven transitions between them.
[0099] Referring to FIG. 16, and in more detail, in one embodiment
a determination is made to model a variable with a nonvolatile
state in a block diagram environment for more than one cycle of
introducing and removing power from the environment. In some
embodiments, variable 1608 inherits a value from a parent variable
when the parent variable is powered up. In these embodiments, the
value of the variable 1608 persists from one invocation of the
chart 1602 to the next. In one embodiment, rather than resetting
the value of the variable 1608, a property of the variable 1608 in
chart 1602 enables a user to specify that the value of the local
variable 1608 is not reset when the parent of the chart cycles its
power. In this embodiment, the user defines for local data when the
value of a variable 1608 persists in spite of the removal of power
or the introduction of power.
[0100] Referring now to FIG. 17, a block diagram depicts one
embodiment of a variable with a nonvolatile state in an embedded
MATLAB block diagram environment. In this embodiment, the block
diagram environment 1700 includes an editor 1702, data input 1704,
data output 1706, variable 1708, and variable 1710.
[0101] In one embodiment, the variable 1708, labeled "state," is
defined to be "persistent." In this embodiment, its value is reset
only when the parent system powers up. In one embodiment, the
variable 1710, labeled "power cycles," is declared to be
nonvolatile.
[0102] FIG. 18 depicts one embodiment of code generated for an
embedded MATLAB environment in which a variable has a nonvolatile
value. In this embodiment, during a simulation, variable 1810 is
initialized once at time 0. In one embodiment, when code is
generated for an embedded application, variable 1810 is not
initialized. In this embodiment, the environment is responsible for
any initialization of nonvolatile memory that occurs.
[0103] Referring now to FIG. 19, a block diagram depicts, in
greater detail, one embodiment of the steps taken to model a
nonvolatile variable in a block diagram environment such as a
Stateflow chart with a history junction. In brief overview, FIG. 19
shows a Stateflow chart with a History Junction at its top level. A
history junction is used to represent historical decision points in
the Stateflow diagram. The decision points are based on historical
data relative to state activity. Placing a history junction in a
superstate indicates that historical state activity information is
used to determine the next state to become active.
[0104] Referring now to FIG. 19, and in greater detail, in one
embodiment, a decision is made to model a nonvolatile history
junction. In this embodiment, because of the nonvolatile history
junction, when the parent of the chart is powered down and then
powered up again, the chart does not reinitialize. The state that
was active when the parent of the chart powered down continues to
be the active state when that parent is powered up again.
Furthermore, all local variables in the chart are nonvolatile so
that their values are not reset due to the parent of the chart
being powered down.
[0105] As described in FIG. 8 above, each block 802 in a block
diagram 800, and for each sub-component 804 or 808 in a block 802,
state control is intrinsic and independent. That is, each
sub-component 804 or 808 within a block 802 and each block 802
within a block diagram 800 retains control over its own behavior.
State reset and initialization for each block 802, and for each
sub-component 804 within the block 802, transcends any hierarchical
state behavior or properties.
[0106] Referring now to FIG. 20, a block diagram depicts one
embodiment of a system 2000 containing blocks that reference both
volatile and nonvolatile memory, including a volatile delay block
2002 and nonvolatile delay block 2004. In one embodiment, the top
delay block in FIG. 20, volatile delay block 2002, specifies that
its memory is volatile. In another embodiment, the bottom delay
block, nonvolatile delay block 2004 specifies that its memory is
nonvolatile. In these embodiments, FIG. 20 depicts the initial
conditions of the memory of the two blocks 2002 and 2004 as having
the values 2 and 5.
[0107] Referring to FIG. 20 in greater detail, in one embodiment, a
nonvolatile memory stores a value even when the software with which
it is used in conjunction is not powered up. Accordingly, in some
embodiments, the memory of nonvolatile delay block 2004 will be
initialized to 5 at the start of simulation, independent of when or
even if the system is initially powered up. In one embodiment, the
memory of volatile delay block 2002 is not active when the software
is not executing, and therefore its initialization to 2 is deferred
until the system powers up. Furthermore, the initialization for
volatile delay block 2002 is repeated each time the system powers
up. In these embodiments, each time the system is powered down, the
memory for volatile delay block 2002 is reset by default to 0,
while the memory for nonvolatile delay block 2004 remains set at
its current value.
[0108] Referring now to FIG. 21, one embodiment is depicted of
generated code for simulation of a system in the present invention.
In one embodiment, code is generated for an accelerated simulation
of the system as well as its parent context. In this embodiment,
the code uses a software mode to keep track of the state of the
power signal, to enable simulation of the system being powered up
and powered down by the software environment. In one embodiment,
the software mode comprises powering up the system from an
unpowered state. In another embodiment, the software mode comprises
the system already being powered up. In still another embodiment,
the software mode comprises powering down the system from a powered
state. In yet another embodiment, the software mode comprises the
system already being powered down.
[0109] Referring now to FIG. 21, and in greater detail, lines 2
through 4 of the code initialize nonvolatile memory at time 0, to
simulate that this memory's value persists in the software
environment, independent of power being applied to the software of
the system. Line 10 initializes the volatile memory of the system
each time it transitions from powered down to powered up. Lines
25-28 reset the values of the volatile memory and the system
outputs to 0 by default when the software is powered down; if the
data is of a fixed-point type, it will be reset to integer 0 by
default.
[0110] In one embodiment, depicted in FIG. 22, code is used to
detect transitions from a powered down state to a powered up state.
In this embodiment, the code would be used in conjunction with the
detectPowerState( ) code, depicted in FIG. 21. In another
embodiment, where standalone code is being generated for usage of
the system as a software component in a real-world software
environment, then there is no need to simulate the power down
action, and the system merely needs to keep track of time in order
to initialize its data at time 0. FIG. 23 depicts one embodiment of
code generated independent of any software environment. In this
embodiment, the code may be used to initialize data at time 0 but
no software is generated to initialize the nonvolatile memory.
[0111] The present invention may be provided as one or more
computer-readable programs embodied on or in one or more mediums.
The mediums may be a floppy disk, a hard disk, a compact disc, a
digital versatile disc, a flash memory card, a PROM, a RAM, a ROM,
or a magnetic tape. In general, the computer-readable programs may
be implemented in any programming language. Some examples of
languages that can be used include C, C++, C#, or JAVA. The
software programs may be stored on or in one or more articles of
manufacture as object code.
[0112] While the invention has been shown and described with
reference to specific preferred embodiments, it should be
understood by those skilled in the art that various changes in form
and detail may be made therein without departing from the spirit
and scope of the invention as defined by the following claims.
* * * * *