WO2001038978A1 - Pilote pour automate fini et methodes d'utilisation - Google Patents

Pilote pour automate fini et methodes d'utilisation Download PDF

Info

Publication number
WO2001038978A1
WO2001038978A1 PCT/US2000/032216 US0032216W WO0138978A1 WO 2001038978 A1 WO2001038978 A1 WO 2001038978A1 US 0032216 W US0032216 W US 0032216W WO 0138978 A1 WO0138978 A1 WO 0138978A1
Authority
WO
WIPO (PCT)
Prior art keywords
state
state machine
event
machine driver
input
Prior art date
Application number
PCT/US2000/032216
Other languages
English (en)
Inventor
Vladimir I. Miloushev
Peter A. Nickolov
Becky Hester
Leonid Kalev
Original Assignee
Z-Force Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Z-Force Corporation filed Critical Z-Force Corporation
Priority to AU25745/01A priority Critical patent/AU2574501A/en
Publication of WO2001038978A1 publication Critical patent/WO2001038978A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4498—Finite state machines

Definitions

  • the present invention relates generally to the field of object-oriented software engineering, and more specifically to configurable state machine drivers.
  • object-oriented analysis, design, programming and testing has become the predominant paradigm for building software systems.
  • a wide variety of methods, tools and techniques have been developed to support various aspects of object-oriented software construction, from formal methods for analysis and design, through a number of object-oriented languages, component object models and object-oriented databases, to a number of CASE systems and other tools that aim to automate one or more aspects of the development process.
  • object composition The focus of object composition is to provide methods, tools and systems that make it easy to create new objects by combining already existing objects.
  • An excellent background explanation of analysis and design methodology based on object composition is contained in
  • Composition-based development Composition - building new objects out of existing objects - is the natural way in which
  • composition to build software systems is quite limited.
  • One reason for this is that supporting software design by composition has proven to be extremely difficult. Instead, inferior approaches, which are limited and often hard-to-use, have been used because they were easier to support. Approaches such as single and multiple inheritance, aggregation, etc., have been
  • composition-based systems include HOOD (see earlier reference), ObjecTime
  • This system was commercialized in several products, including ClassMagic and DriverMagic, and has been used to create a variety of software components
  • a state machine is a system with discrete inputs and outputs.
  • the system can be in any
  • One of the simplest state machines is a bit of computer
  • Inputs to the bit can be "set-to-0", “set-to-1” and “invert".
  • the output is a value, 0 or 1.
  • Every digital system contains a large number of state machines of varying complexity.
  • state machines are traditionally used in text parsing and communication protocols.
  • Most modern compilers for computer languages use state machines to parse the
  • Such software accepts input from various sensors and exerts control using actuators.
  • the device controlled by this software needs to respond predictably and within a predetermined amount of time to various events that occur in the physical world.
  • state machines are mostly used to determine what the response of the controlled system needs to be, depending on the incoming stimulus (input)
  • examples can receive non-deterministic input and must be able to provide adequate reaction. Furthermore, in applications such as communication protocols and embedded software, the
  • State machines are typically implemented in software by assigning one or more variables as "state” variables, and providing individual functions for each input.
  • the output is represented by the various actions taken by the input functions, depending on the state
  • state machine to code is not a well formalized process and frequently invites personal judgment, interpretation and errors. This method of implementing state machines also makes
  • these utilities generate program code that needs to be further translated to machine code by a compiler; this limits the ability of modifying the state
  • Inputs may be bi-directional, requiring a synchronous response that indicates the
  • Inputs typically carry data (e.g., the payload of a network packet that arrived in the system);
  • Outputs may be bi-directional, where the action taken by the state machine may succeed or fail;
  • Outputs may need to carry data; 5. As the actions taken by the software during processing of an input are non-atomic, another input may enter the software implementation before the processing of the previous
  • object-oriented programming is orthogonal to the application of state machines: i.e. there is no intersection between the two. This is, of course,
  • state transition diagram also known as a statechart.
  • object-oriented methods and systems provide nothing to support the implementation of «tat ⁇ » t ⁇ mr-hin p « ( nth ⁇ r than t p instantiation of state variables). All implementation problems described in the previous section remain: manual translation to code, subtle defects and interoperability problems, model inconsistencies, and race conditions. Even greater expertise is required to implement state machines in object systems: in order to implement a state machine properly within a given object model, the engineer
  • Logix Rhapsody provide support for implementing state machines. They allow the engineer
  • the state machine is
  • the present invention is a configurable state machine driver part for assembling software components that implement state machine functionality and methods of use for the driver part.
  • the driver part provides a fine-granularity, easily reusable object that
  • the present invention further provides a reusable
  • the present invention can be configured as a
  • part in a software system comprising a first terminal for receiving state machine inputs, a second terminal for sending state machine action events, a state variable for keeping the current state of a state machine, a property for configuring said part with a state transition table, means for changing the value of said state variable based on a first input received through said first terminal and based on the value of said state variable at the time said first input was received, and means for choosing either one or no action event to be sent through
  • said second terminal based on said first input and based on the value of said state variable at the time said first input was received.
  • the present invention includes a method for designing a state machine in a software system.
  • the method comprises designing a state machine driver object class that receives at
  • At least one first state machine input keeps at least one state variable, performs at least one state
  • the method further comprises
  • the present invention also includes a method for implementing a hierarchical state machine in a software system, wherein the software system contains a plurality of state machine driver objects and the hierarchical state machine has a plurality of master states and
  • the method comprises creating a first state machine driver
  • the present invention includes a method for designing a state machine in a software system, said software system having at least one object class and having at least
  • one configurable state machine driver class said method comprising designing a state
  • transition chart for said state machine, identifying the state machine actions that need to be performed on the state transitions, converting said state transition chart to a state machine descriptor in a format required bv said confieurable state machine driver class, designing an action handler class that implements the identified state machine action, and designing a
  • Figure 1 illustrates a preferred boundary of a DM FSM part constructed according to the present invention
  • Figure 2 illustrates an advantageous use of the DM_FSM part
  • Figure 3 illustrates the internal structure of a state machine assembly utilizing the
  • Figure 4 illustrates an application of the DM FSM part
  • Figure 5 illustrates an advantageous use of the DM FSM part in which a synchronous
  • event buffer with a postpone, SEBP is used to buffer events that cannot be accepted in the
  • Figure 6 illustrates using reusable parts to reduce the size of the state machine table of the present DM_FSM part
  • Figure 7 illustrates the use of a pre-processor to translate incoming events to inputs on
  • Figure 8 illustrates an application of the present DM FSM part to handle events from two event streams;
  • Figure 9 illustrates the use of the present DM FSM part to build a hierarchical state
  • Figure 10 is a state transition diagram for the sample hierarchical state machine of
  • Figure 9 Figure 9; Figure 11 illustrates the use of the present DM_FSM part to build a pair of synchronized state machines;
  • Figure 12 is a state transition diagram for a sample device controller state machine
  • Figure 13 is a state transition diagram for a sample lexical analyzer state machine.
  • Adapter apart which converts one interface, logical connection contract and/or physical connection mechanism to another. Adapters are used to establish connections between parts that cannot be
  • Aliases are used primarily to provide alternative identification of an entity, usually encapsulating the exact structure of the original name or path.
  • Bind or binding an operation of resolving a name of an entity to a pointer, handle or other identifier that can be used to access this entity For example, a
  • component factory provides a bind operation that gives access to
  • Bus part a part which provides a many-to-many type of interaction between other parts.
  • the name "bus” comes from the analogy with network
  • Ethernet that are based on a common bus through which every computer can access all other computers on the network.
  • Component an instantiable object class or an instance of such class that can be manipulated by general purpose code using only information
  • a Microsoft COM object is a component, a Win32 window is a component; a C++ class without run-time type
  • RTTI RTTI information
  • Component model(s) a class of object model based on language-independent definition of objects, their attributes and mechanisms of invocation. Unlike object-oriented languages, component models promote modularity
  • Connection an association between two terminals for the purposes of transferring data, invoking operations or passing events.
  • Connection broker an entity that drives and enforces the procedure for establishing connections between terminals. Connection brokers are used in the
  • present invention to create connections exchanging the minimum necessary information between the objects being connected.
  • Connection direction of a characteristic of a connection defined by the flow of control on it. Connections can be uni-directional, such as when only one of the
  • participant participants invokes operations on the other, or bi-directional, when each of the participants can invoke operations on the other one.
  • connection direction of data flow a characteristic of a connection defined by the dataflow on it.
  • a function call on which arguments are passed into the function but no data is returned has uni-directional dataflow as
  • mechanism a generic mechanism of invoking operations and passing data through connections. Examples of physical mechanisms include
  • synchronosity a characteristic of a connection which defines whether the entity that invokes an operation is required to wait until the execution of the operation is completed. If at least one of the operations defined by the logical contract of the connection must be synchronous, the connection is assumed to be synchronous,
  • Container an object which contains other objects.
  • a container usually
  • Control block see Data bus.
  • Critical section a mechanism, object or part the function of which is to prevent
  • Data bus a data structure containing all fields necessary to invoke all operations of a given interface and receive back results from them.
  • interfaces based on data buses are easier to de-synchronize, convert, etc.
  • Descriptor table an initialized data structure that can be used to describe or to direct a process. Descriptors are especially useful in conjunction with general rmrnnse nro ⁇ ram c. s ⁇ e. T Tsing properly designed descriptor tables, such code can be directed to perform different functions in a flexible way .
  • De-serialization part of a persistency mechanism in object systems A process of
  • De-synchronizer a category of parts used to convert synchronous operations to
  • any interface with unidirectional data flow coinciding with the flow of control can be de-synchronized using such a part.
  • Event-driven designs model objects as state machines which
  • a notification or request typically
  • Event external An event caused by reasons or originated outside of the scope of a
  • OLE COM control of general purpose code.
  • the mechanism used by OLE COM to create object instances is an abstract factory; the operator "new" in C++ is not an abstract factory .
  • Group property a property used to represent a set of other properties for the
  • assembly containing several parts may define a group property
  • Indicator a category of parts that provides human-readable representation of the data and operations that it receives. Used during the development process to monitor the behavior of a system in a given
  • Input a terminal with incoming flow of control.
  • directional attributes such as incoming and outgoing are always defined from the viewpoint of the object on which the terminal is defined.
  • Interaction incoming in a context of a given object, an interaction that transfers data
  • the direction is preferably determined by the direction of the transfer of control.
  • the direction is preferably determined by the direction
  • Message-based pertains to a physical mechanism of access in which the actual binding of the requested operation to code that executes this operation on a given object is performed at call time.
  • OLE COM a standard of defining interfaces specified and enforced by COM.
  • Interface v-table a physical mechanism of implementing interfaces, similar to the one specified by OLE COM.
  • Marshaler a category of parts used to convert an interface which is defined in the scope of a single address space to a logically equivalent
  • Multiplexor a category of parts used to direct a flow of operations invoked on
  • Name a persistent identifier of an entity that is unique within a given scope. Most often names are human-readable character strings; however, other values can be used instead as long as they are persistent.
  • Name space the set of all defined names in a given scope.
  • Name space joined a name space produced by combining the name spaces of several parts.
  • Object composite an object that includes other objects, typically interacting with each other.
  • Composites usually encapsulate the subordinate objects
  • Parameterization a mechanism and process of modifying the behavior of an object by
  • Part an object or a component preferably created through an abstract factory and having properties and terminals. Parts can be assembled into structures at run-time.
  • Property interface an interface which defines the set of operations to manipulate properties of objects that implement it. Typical operations of a
  • property interface include: get value, set value, and enumerate properties.
  • Property mechanism a mechanism defining particular ways of addressing and accessing properties.
  • a single property interface may be implemented using different property mechanisms, as it happens with parts and
  • Proxy program code, object or component designed to present an entity or a system in a way suitable for accessing it from a different system.
  • Repeater a category of parts used to facilitate connections in cases where the number of required connections is greater than the maximum
  • Return status a standardized type and set of values returned by operations of an interface to indicate the completion status of the requested action
  • Serialization part of a persistency mechanism in object systems A process of
  • Structured storage a mechanism for providing persistent storage in an object system where objects can access the storage separately and independently
  • Terminal a named entity defined on an object for the purposes of establishing
  • Terminal cardinality the maximum number of connections in which a given terminal can
  • Terminal exterior a terminal, preferably used to establish connections between the
  • Terminal interior a terminal, of an assembly, preferably used to establish connections between the assembly to which it belongs and one or more subordinate objects of this assembly.
  • Terminal interface an interface which defines the set of operations to manipulate terminals of objects that implement it.
  • Terminal mechanism a mechanism defining particular ways of addressing and connecting
  • a single terminal interface may be implemented using
  • Thread of execution a unit of execution in which processor instructions are being executed sequentially in a given execution context.
  • a single-processor system has only one thread of
  • each instance of a system thread object defines a separate thread of execution.
  • the preferred embodiment of the present invention is implemented as software component objects (parts).
  • the present part is preferably used in conjunction with the
  • Patent Application Serial No. 09/640,898 entitled SYSTEM OF REUSABLE SOFTWARE
  • ClassMagic and DriverMagic used throughout this document, refer to commercially available products incorporating the inventive "System for Constructing
  • One inventive aspect of the present invention is the ability to represent many of the
  • Events provide a simple method for associating a data structure or a block of data, such as a received buffer or a network frame, with an object that identifies this structure, its contents, or an operation requested on it.
  • Event objects can also identify the required distribution discipline for handling the event, ownership
  • event objects defined as described above can be used to express notifications and requests that can be distributed and processed in an asynchronous
  • Such passing preferably is done by
  • the I DRAIN interface is a standard interface as described in the '675 application, it has only one operation - "raise”, and is intended for use with event objects.
  • sending an event refers to a part invoking its output I DRAIN terminal
  • receiving an event refers to a part's I_DRAIN input terminal being invoked.
  • An event object is a memory object used to carry context data for requests and for
  • An event object may also be created and destroyed in the context of a hardware interrupt and is the designated carrier for transferring data from interrupt sources into the normal flow of execution in systems based on the '675 system.
  • An event object preferably
  • event context data a data buffer (referred to as the event context data or event data) and the following "event fields":
  • event ID - an integer value that identifies the notification or the request.
  • attributes an integer bit-mask value that defines event attributes.
  • the other half is reserved as event-specific and is defined differently for each different event (or group of events).
  • the data buffer pointer identifies the event object. Note that the "event fields" do not necessarily reside in the event data buffer, but are accessible by any part that has a pointer to the event data buffer.
  • the event objects are used as the operation data of the I_DRAIN
  • This interface 's single operation - raise. This interface is intended for use with events and there
  • Notifications are "signals" that are generated by parts as an indication of a state change or
  • the requester is notified of the completion by a "callback", which takes a form of invoking an incoming operation on one of its terminals, typically, but not necessarily, the same terminal through which the original request was issued.
  • the "callback” operation is preferably invoked with a pointer to the
  • An event recoder part in combination with other parts may be used to transform notifications into asynchronous requests.
  • Requests may be completed either synchronously or asynchronously.
  • the originator of a request (the request 'owner') creates and owns the event object.
  • a special data field may be reserved in the request data buffer, referred to as "owner context" - this field is private to the owner of the request and may not be overwritten by
  • a part that receives a request may:
  • a part that receives a request may re-use the request's data buffer to issue one or more requests through one of its I_DRAIN terminals, as long as this does not violate the rules
  • desynchronizers which preferably provide a queue for the pending requests and take care of setting the "status" field in the completed requests.
  • an object interface such as a v-table interface
  • an event similar to the events described above. This is especially true in the case of interfaces which are defined as
  • bus-based interfaces in such interfaces, data arguments provided to the operation, as well as, data returned by it, is exchanged by means of a data structure called bus.
  • operations of the same bus-based interface are defined to accept one and the same bus structure.
  • Another inventive aspect of the present invention is that the time-based transitions in state
  • Timers are event sources that generate outgoing events spontaneously, upon expiration of a given period of time, as is the case with a watchdog timer, or
  • timers provide the ability to perform time-dependent functionality
  • timeouts in response to events generated by them.
  • Timers preferably have a bi-directional terminal, through which they generate, or "fire”, outgoing events and receive control events, preferably "enable” and “disable”.
  • timers preferably define properties through which their operation can be parameterized, such
  • a timer When assembled in a structure with other parts, a timer preferably remains inactive until it receives the first "enable” event from one of these parts. After becoming enabled, the timer
  • the DM FSM of the present invention is a configurable finite state machine driver that maintains the current state and performs state transitions for a state machine implementation. This eliminates the requirement for state machine handlers to have specific knowledge about
  • the state machine that DM_FSM drives is specified by a descriptor and passed to the
  • the descriptor contains information about the possible states and the set of possible events that can be received in each state. For each (state, event) pair, the
  • descriptor specifies the next state and an action to be taken. Each action may contain
  • one action may be specified for each (state, event) pair.
  • the DM FSM When the DM FSM receives events on its "in” terminal, it locates in the descriptor the corresponding (state, event) pair, makes the specified state transition, and performs the specified action.
  • the DM FSM may emit notifications out its "nfy" terminal upon entering a
  • the notifications may be useful to synchronize the state of multiple state machines.
  • the DM FSM may not be re-entered with the process of sending "enter
  • the DM FSM generates an additional notification out its nfy terminal upon any state transition after the action has been performed.
  • the DM FSM is parameterized with
  • the DM FSM may be re-entered during the context of sending this notification.
  • DM FSM The preferred boundary of the DM FSM is illustrated in Fig. 1.
  • O u t Out DRAIN Events are sent out this terminal as specified by the action taken for a specific (state, incoming event) pair.
  • the events and notifications that the DM FSM receives on its in terminal and/or generates out its out terminal are specified in the state machine descriptor that parameterizes the DM_FSM.
  • the DM_FSM sends the following events out its nfy terminal:
  • ⁇ ID is specified in the state machine descriptor.
  • the ID is specified by the state_chg_ev property.
  • the DM_FSM has found an error in the state machine descriptor during operation or has failed to allocate memory when generating an event.
  • the events received and sent by the DM FSM are preferably defined to have a common
  • Initial state uint32 Identifier for initial state. The default value is 0.
  • Unrecognized_s uint32 Status returned for unrecognized incoming events.
  • the default value is CMST_NOT_SUPPORTED.
  • Busy_s uint32 Status returned for incoming events when the DM FSM is in a non-atomic state while sending enter/leave state notifications.
  • the default value is CMST UNEXPECTED.
  • State_chg_ev uint32 Specifies the event ID that the DM FSM sends out its nfy terminal on each state transition. If the value is 0, the DM_FSM does not generate "state changed" notifications. The default value is 0.
  • the DM FSM performs a logical AND between this value and the incoming event attributes when setting the attributes for a generated event. This property must not contain the CMEVT_A_ASYNC_CPLT and CMEVT_A_COMPLETED attributes. The default is
  • the DM FSM performs a logical OR between this value and the incoming event attributes when setting the attributes for a generated event. This property must not contain the CMEVT_A_ASYNC_CPLT attribute. The default is 0.
  • Exc_part_name asciz Part name to use when generating exception events.
  • the default is "DM FSM”.
  • the DM FSM is parameterized with a state machine descriptor that specifies a next state and action for each (state, input) pair. Each state contains a state identifier and event Ids for notifications to send when entering and/or leaving the state.
  • the DM FSM accepts state identifiers between 0 and 63 for a total of 64 states.
  • the "input" consists of an event identifier and a flag optionally specifying the required
  • the flag specifies one of the following:
  • the CMEVT A COMPLETED attribute is set (i.e., the event is a completion event for a previous request)
  • Each entry in the descriptor, indexed by the (state, input) pair, specifies the following
  • next state - Specifies the next state that the
  • DM FSM transitions to before performing the action. If the value of this parameter is _SAME_ (-1), then the DM FSM performs no state transition.
  • Action - Specifies the action that the DM FSM is to take. The actions are described below.
  • Action-specific data Specifies any additional parameters necessary for the DM_FSM to carry out the action.
  • the action specific data for each action is described below.
  • the descriptor is preferably defined using a set of macros. See the DM_FSM State Machine Reference herein for a complete reference of the descriptor macros and examples of their use.
  • the DM FSM For each (state, input) pair, the DM FSM can perform one of three actions:
  • the DM FSM can forward the event (as is) through to its out terminal or modify the
  • the DM_FSM provides the option to
  • This action also has the option of having the
  • DM FSM return a status other than the status returned from the forwarded event.
  • the DM FSM can generate a new event out its out terminal. This action has additional parameters that specify how the DM_FSM is to deal with the event data:
  • This action also has the option of having the DM FSM return a status other than the
  • the DM FSM can serve the incoming event by returning a specified status.
  • the DM FSM supports the following categories of incoming events:
  • Synchronous Completion Requests These are requests that must be completed synchronously. The issuer expects return status and/or data.
  • the DM FSM preferably does not treat the different event categories differently, but it
  • the DM FSM will preferably generate EV EXCEPTION events out its nfy terminal if it
  • the DM FSM fails to allocate an event bus when performing a generate action.
  • the DM FSM is parameterized with the exception Ids that it generates for each of the
  • the DM FSM can generate other exceptions on other types of errors.
  • the default is 0 (do not generate exception) exc no memory uint32 Exception ED to generate when the DM_FSM fails to allocate memory during the processing of a generate action.
  • the default is 0 (do not generate exception) 3.3. Responsibilities
  • the DM FSM preferably has the following responsibilities:
  • the DM FSM implements the state machine provided to it via its fsm_descp property.
  • the organization of the state machine is (state, event) -> (new state, action).
  • the checked build of the DM FSM validates the correctness of the state machine descriptor upon activation.
  • the DM FSM performs the following validation:
  • the DM_FSM When the DM_FSM receives an event on its in terminal, it indexes into the descriptor based on the current state and locates an entry with event ID matching the incoming event ID.
  • the DM FSM performs the action specified by the entry.
  • STATE (id,enter_id, leave id) Specify a state entry.
  • the id parameter specifies the state identifier.
  • the enter_id parameter specifies the ID of the notification to send when entering the state or EVJNULL to not generate a notification.
  • the leave id parameter specifies the ID of the notification to send when leaving the state or EV NULL to not generate a notification.
  • ON(event,state,action) Specify an event entry.
  • the event parameter specifies the incoming event. Use the eve «t definition macros defined below to specify this parameter.
  • the state parameter specifies the next state
  • the action parameter specifies the action to take. Use the action definition macros defined below to specify this parameter. To specify no state change, set state to _SAME_.
  • the STATE_MACHINE and END_STATE_MACHINE macros define a new part similar to the one described at the beginning of the DM_FSM Application Notes.
  • the DM_FSM defines the following macros to specify the event parameter of the ON
  • Macro Description eventX (id, attr, mask) Generic definition for an incoming event.
  • event Specify incoming event where any attributes may be set (i.e., the
  • DM_FSM accepts any type of event).
  • CMEVT_A_COMPLETED attribute is cleared).
  • completion (id) Specify an incoming event where the CMEVT_A_COMPLETED attribute is set.
  • the DM FSM defines the following macros to specify the action parameter of the ON
  • the type parameter specifies the action type [FSM_AT_XXX].
  • the status parameter specifies the status to return if overriding the return status.
  • the id field specifies the event ID to generate.
  • [FSM_AF_XXX]. serve Define an event where the DM_FSM services the event by returning the status specified by status.
  • postpone Define an event where the DM FSM postpones the event by returning
  • fwd Define an event where the DM FSM fwd_override (status) services the event by forwarding the event to its out terminal without modification.
  • DM_FSM returns the status specified by the status parameter.
  • the DM FSM sends the notification out its nfy terminal.
  • the DM_FSM sends the notification out its nfy terminal.
  • the DM_FSM After sending the state change notification, the DM_FSM performs the specified action,
  • the event ID that is sent is the value specified in the state_chg_ev property.
  • the DM FSM processes SERVE actions by returning the status specified by the action
  • the DM FSM When the DM FSM processes a FORWARD action, it first checks if it needs to modify
  • the DM FSM sets the event ID to the one
  • the DM_FSM then forwards the event out its out terminal.
  • the DM FSM restores the original event ED. If it is specified to override the return status, the DM_FSM
  • the DM_FSM processes a GENERATE action by performing the following steps:
  • the DM_FSM allocates a bus with the same size and attributes as the incoming event bus.
  • the DM_FSM copies all data following the CMEVENT HDR portion of the new event bus to the original event bus before returning.
  • the DM_FSM When the DM_FSM encounters an error that requires an exception notification to be generated, the DM_FSM verifies that the property that specifies the exception ED to raise is
  • the DM_FSM provides the following information in the B EV EXC bus:
  • FIG. 2 A simple example of a preferred use of the DM FSM is illustrated in Fig. 2. In this
  • the HDLR part need not be a coded part - it may be assembled out of other parts.
  • the DM_FSM receives events from an external source on its in terminal.
  • the DM FSM makes the required state change and performs the specified action.
  • DM FSM may result in the DM FSM sending the same event or a different event out its out terminal to be processed by the HDLR.
  • the HDLR part When the HDLR part receives an event, it performs the necessary processing.
  • the HDLR part has a feedback terminal (fbk) through which it can feed events into the state machine for
  • the DM FSM uses a state machine descriptor (supplied from outside by the property
  • each state, and for each (state, input) pair describes the next state and an action to be taken.
  • the descriptor is preferably an array of the following structure:
  • FSM_AT_FORWARD #define FSM_AF_RESTORE_ID 0x02 restore event ED if action
  • FSM_AT_FORWARD #define FSM AF OVRD STAT 0x04 override return status if action
  • FSM_ET_EVENT uint32 attr if entry type is FSM_ET_ENTRY, specifies event attributes that must be set uint32 attr mask if entry type is FSM_ET_ENTRY, specifies an attribute mask that is
  • the DM FSM preferably defines several convenience macros that aid in defining the state machine descriptor.
  • the macros are described below:
  • fwd_modify (new_ev_id, restore) Define an event where the DM FSM fwd_modify_override (new_ev_id, services the event by modifying the status, restore) event id to new_ev_id before forwarding the event to its out terminal.
  • the DM_FSM returns the status specified by the status parameter.
  • gen(new_ev_id) Define an event where the DM_FSM gen override (new ev id, status) generates a new event of size
  • gen cpy in (new ev id, cpy_out) Define an event where the DM FSM gen_cpy_in_override (new_ev_id, generates a new event with same size status, cpy_out) as incoming event bus and event id specified by new ev id and copies the data following the
  • the DM FSM forwards the event to its out terminal.
  • the cpy out parameter specifies whether the DM FSM is to copy the contents of the new event bus to the original event bus before returning.
  • the DM FSM returns the status specified by the status parameter.
  • Macro Description gen cpy out (new evjd) Define an event where the DM FSM gen_cpy_out_override (new_ev_id, generates a new event with same size status) as incoming event bus and event id specified by new_ev_id and copies the incoming data following the CMEVENT_HDR portion of the bus to the new event bus.
  • the DM FSM forwards the event to its out terminal and before returning, copies the bus data from the new event bus back to the original event bus before returning.
  • the DM FSM returns the status specified by the status parameter.
  • END STATE MACHENE macros a part having the same boundary as the DM FSM is defined.
  • the name that is given to the STATE MACHENE macro is used as the part's class name. For this reason, the state machine descriptor should be declared in a separate source file.
  • the resulting part exposes all properties of the DM FSM except for the fsm descp and exc_part_name properties, which are hard parameterized by the part.
  • the DM FSM part may be used in a number of different scenarios. The following
  • FSMX is an assembly containing the
  • HDLR part need not be a coded part - it may be assembled from other parts.
  • FSMX makes the
  • the action may result in FSMX
  • the EEDLR part When the HDLR part receives an event, it performs the necessary processing.
  • the EEDLR part has a feedback terminal (fbk) through which it can feed events into the state machine for the purpose of handling error conditions or other processing. En very simple cases, the feedback terminal and connection may not necessary. Examples of Use
  • the postpone use case enables the state machine to postpone processing of received events that are received at an inappropriate time (i.e., invalid state) until such a time that the event may be processed (i.e., valid state).
  • This use case is illustrated in Fig. 5. It is similar to
  • FSMX i.e., state machine
  • FSMX sends the "state change" notification, which causes the NFY part to generate an EV FLUSH event to
  • SEBP Upon receiving EV FLUSH, SEBP resubmits all postponed events to FSMX.
  • FSMX For each event, FSMX can either process the event or postpone it again.
  • DM DSV distributor for service
  • the DM DSV is parameterized to recognize events that are not recognized by the state
  • This preprocessing may involve translating one event ID to another, re-coding the event ED based on some field in the event bus, or generating multiple events from a single input event.
  • the pre-processing of events is performed by the XLT part as illustrated in Fig. 7. This
  • the XLT part can be a coded part or assembly of reusable
  • the translation of events is frequently used in communications where different frame types are sent with the same carrier event (e.g., EV FRAME).
  • the XLT part translates
  • each frame type to a different event using the frame type field in the frame header.
  • This use case involves the situation where the state machine must process events from two or more event streams such as in a device driver controller as illustrated in Fig. 8.
  • the event EDs may or may not be unique. Ef incoming event EDs are not unique, then the
  • incoming events on at least one stream should be pre-processed before being fed into the state machine as illustrated by the XLT part in Fig. 8.
  • a typical device controller has two bi-directional inputs (e.g., cmd and dev as shown in the diagram above). It receives requests and sends completion events via the cmd terminal. Requests and responses are sent/received to/from the device via the dev terminal.
  • the above use case illustrates how the FSMX and the HDLR parts can be assembled in such a way that the incoming events from each input are fed into the state machine. If the
  • event Ids sent to each input may be the same, then a part, such as XLT in the above diagram,
  • the HDLR part may send a
  • Fig. 9 illustrates an hierarchical state
  • state machine 2 built to implement the state transition table illustrated in Fig. 10.
  • the states of state machine 2 are valid only when state machine 1 is in state S2. En this example, state machine
  • the link state machine has a subordinate state machine for the normal state.
  • HDLR part There may be a separate HDLR part for each state machine.
  • a multiplexer may be used to direct
  • the subordinate state machine may transition to a known (disabled) state when the S2
  • main state is left, or it may retain the sub-state.
  • the DM FSM's "state enter/leave" notifications may be used to synchronize the states of
  • the two state machines are entirely separate with separate inputs and separate HDLR parts. However, it is possible that both state machines feed into a single HDLR part.
  • the state enter/leave notifications are used to synchronize the two state machines.
  • the following is an example of defining a state machine descriptor to be used by FSM for a device controller of a magnetic card reader.
  • the example state machine has the state
  • the device controller has received the start event and is waiting for a response from the device.
  • the device controller has received a request to read card data and is waiting for a response from the device.
  • the device controller has received a property request that requires communication with the device.
  • the device controller has sent a property request to the device and is waiting for the response.
  • the device controller has received a stop request while waiting for a response from the device.
  • the state machine has the following incoming events:
  • the state machine has the following outgoing events:
  • EV_CMD_WRETE Command to write data to a magnetic card EV_RSP_READ Response to read request [EV CMD READ] EV_RSP_GET Response to get request [EV CMD GET] EV_REFUSE_GET An EV CMD GET command cannot be processed in the current state.
  • EV REFUSE WRITE - An EV CMD READ command cannot be processed in the current state.
  • EV_CMD_GET_W_P - An EV_CMD_GET command has been received when END there is already a pending command.
  • the state machine descriptor has the following definition:
  • FSM_STATE (EDLE, EN NULL, EV_NULL)
  • Lexical Analyzer The following is an example of defining a state machine descriptor to be used by FSM in
  • a lexical analyzer characters are fed into the state machine one at a time.
  • the goal of the lexical analyzer is to parse the following types of fields into tokens:
  • the state machine is based on the following grammar:
  • the state machine has the state transition diagram illustrated in Fig. 13 (error transitions are omitted for brevity and are not shown).
  • the above state machine has the following states:
  • EDLE - ⁇ State machine is in an EDLE state
  • ESCAPE - ⁇ State machine has received a BACKSLASH event, which starts an "escape" field.
  • HEX1 -> State machine has received an X ALPHA event, which specifies that the escape is a hexadecimal number.
  • HEX2 - ⁇ State machine has received the first hexadecimal number.
  • VALUE - ⁇ > State machine has received a L ANGLE event which starts a "value" field. NAME ⁇ State machine is accumulating a value name.
  • the incoming events of the above state machine are character categories.
  • the state machine has the following events:
  • the state machine generates the following events: EVJL1T - ⁇ Process character as a literal
  • This event is generated so that EEDLR can perform any necessary cleanup.
  • the state machine descriptor has the following definition:
  • FSM_STATE (HEX1, EN_NULL, EN_NULL) ON (event (NUMBER ), HEX2 , fwd modify (EV_S_HEX, TRUE) )
  • FSM_STATE (HEX2, EV_NULL, EV_NULL)
  • the Event Drain interface is used for event transportation and channeling.
  • the events are
  • the events sent through this interface can be distributed synchronously or asynchronously. This is indicated by two bits in the attr member of the bus.
  • I DRAIN attributes, see the next section. There are two categories of parts that implement I DRAIN: transporters and consumers.
  • Transporters are parts that deliver events for other parts, without inte ⁇ reting any data except
  • Transporters do not need to do that, they generally pass events through to other parts. Eventually, all events reach consumers and get released. Emplementations that are mixtures between transporters and consumers need to take about proper resource handling whenever the event is consumed.
  • CMEVT_A_CONST Data in the event bus is constant.
  • CMEVT_A_SYNC Event can be distributed synchronously.
  • CMEVT A ASYNC Event can be distributed asynchronously.
  • CMEVT A SYNC ANY Event can be distributed either synchronously or asynchronously. This is a convenience attribute that combines CMEVT_A_SYNC and
  • CMEVT_A_SELF_OWNED Event bus was allocated from heap. Recipient of events with this attribute set are supposed to free the event.
  • D bus contains no external references.
  • the E DRAEN interface is preferably used to send events, requests or notifications. Et only has one operation called "raise.” An event is generated by initializing an event bus and invoking the raise operation. The event bus describes the event. The minimum information needed is the size of the bus, event ED, and event attributes. The binary structure of the event bus may be extended to include event-specific information. Extending the event bus structure is done by using the EVENT and EVENTX macros. Parts that don't recognize the ED of a given event should inte ⁇ ret only the common header: the members of CMEVENTJEDR.
  • the event attributes are divided into two categories: generic and event-specific.
  • the first 16 bits (low word) of the attribute bit area are reserved for event-specific attributes.
  • the last 16 bits (high word) of the attribute bit area are reserved for generic attributes. These are defined by CMAGIC.H (CMEVT_A_XXX).
  • the generic attributes include the synchronicity of the event, whether the event data is constant, and if the event bus is self-owned or self-contained. If the event bus is self-owned, this means that it was allocated by the generator of the event and it is the responsibility of the recipient to free it (if the event is consumed). If the event is self-contained, this means the event bus contains no external references. For the event to be distributed asynchronously, the event bus must be self-owned and self-contained.
  • the state machine driver may be implemented under a system other than the '675 system. 2. As defined herein, the boundary of the configurable state machine driver provides one main input and one main output. However, its boundary may be modified to
  • indexing tuple state, input number, event
  • additional action information will optionally specify through which output number the outgoing event should be sent.
  • the state machine driver can be modified to use polymo ⁇ hic v-table interface or
  • the described embodiment implements a finite automaton, but other automata
  • the state machine driver may be modified to support more or less states than the defined 64 states.
  • the state machine driver implementation looks up for the input event using a sequential search, but a faster implementation can be easily provided.
  • the state transition table is specified using macros that define
  • a method for designing state machines can also be defined. This method includes designing the state machine driver object, which accepts inputs, performs transitions and emits outputs, then designing the action handler object, which
  • a method for implementing state machines may be defined. This method includes .
  • the action handler can be an object coded
  • handler can be established in a variety of ways. One possibility is to use the mechanisms described in the '675 application for establishing a connection
  • action handler object class may derive from the state machine driver class, and the action handler class may implement its input as one or more virtual
  • a method for designing and implementing hierarchical state machines can be
  • the top-level (master) states are assigned to and handled by one instance of the configurable state machine driver, known as the master driver.
  • a separate configurable state machine driver instance (a subdriver) is assigned to and handles
  • the master driver is designed as if the state machine consisted only of the master states; in addition, for each of the master states that has substates, the master driver is configured to issue state enter/leave notifications. These notifications are then fed into the appropriate subdriver assigned to handle the substates of that master state.
  • the state machine descriptor for each subdriver is
  • the master driver and the subdrivers are assembled together with one or more action handlers, similarly to the structure illustrated in Fig. 9, to produce the required full state machine.
  • a method for handling errors in a subordinate state machine can be defined. For example,
  • any conditions that the subordinate state machine cannot handle either the state machine driver or the action handler issues an exception, indicating that the subordinate state machine cannot handle the current situation.
  • a higher level state machine can then take an appropriate action.
  • a network such as a Wi-Fi network
  • a subordinate state machine may handle the packet acknowledgement and recovery protocol between two network nodes; if an error
  • state machine can issue an exception, which will be processed by the TCP/EP connection state machine, which can then either dissolve the connection or use a higher level protocol to recover the communication.
  • a method for uniform processing of state machine input can be defined for

Abstract

Cette invention a trait à un pilote pour automate fini configurable, permettant l'assemblage de composants de logiciel mettant en oeuvre une fonctionnalité d'automate fini (Figure 1). Ce pilote fournit un objet réutilisable à fine modularité contenant la fonctionnalité fondamentale nécessaire à la mise en oeuvre d'automates finis dans un large éventail d'applications de logiciels et de systèmes (Figure 4). Cette invention porte sur un objet logiciel réutilisable pouvant être largement paramétrisé sans que ne soit modifiée sa mise en oeuvre ou que soit demandé le code source, ce qui confère une capacité à modifier et à spécialiser son comportement pour qu'il servir à différentes finalités souhaitées (Figure 8). L'invention concerne également l'utilisation de ce pilote aux fins de la conception et de la mise en oeuvre d'automates finis aux caractéristiques diverses.
PCT/US2000/032216 1999-11-24 2000-11-22 Pilote pour automate fini et methodes d'utilisation WO2001038978A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU25745/01A AU2574501A (en) 1999-11-24 2000-11-22 Configurable state machine driver and methods of use

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16741499P 1999-11-24 1999-11-24
US60/167,414 1999-11-24

Publications (1)

Publication Number Publication Date
WO2001038978A1 true WO2001038978A1 (fr) 2001-05-31

Family

ID=22607293

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/032216 WO2001038978A1 (fr) 1999-11-24 2000-11-22 Pilote pour automate fini et methodes d'utilisation

Country Status (2)

Country Link
AU (1) AU2574501A (fr)
WO (1) WO2001038978A1 (fr)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014035700A1 (fr) * 2012-08-31 2014-03-06 Micron Technology, Inc Insertion d'instructions dans des moteurs d'automate fini
WO2013190416A3 (fr) * 2012-06-23 2014-05-22 Pmda Services Pty Ltd Dispositif informatique permettant des transitions d'états d'automates à états finis récursifs et procédé informatisé permettant la définition, la conception et le déploiement d'automates à états finis récursifs adaptés au domaine et destinés à des dispositifs informatiques de ce type
US9448965B2 (en) 2013-03-15 2016-09-20 Micron Technology, Inc. Receiving data streams in parallel and providing a first portion of data to a first state machine engine and a second portion to a second state machine
US9524248B2 (en) 2012-07-18 2016-12-20 Micron Technology, Inc. Memory management for a hierarchical memory system
US9703574B2 (en) 2013-03-15 2017-07-11 Micron Technology, Inc. Overflow detection and correction in state machine engines
WO2018086677A1 (fr) * 2016-11-09 2018-05-17 Abb Schweiz Ag Procédé de détermination de transitions possibles d'états de système
US10019311B2 (en) 2016-09-29 2018-07-10 Micron Technology, Inc. Validation of a symbol response memory
US10146555B2 (en) 2016-07-21 2018-12-04 Micron Technology, Inc. Adaptive routing to avoid non-repairable memory and logic defects on automata processor
US10268602B2 (en) 2016-09-29 2019-04-23 Micron Technology, Inc. System and method for individual addressing
US10417236B2 (en) 2008-12-01 2019-09-17 Micron Technology, Inc. Devices, systems, and methods to synchronize simultaneous DMA parallel processing of a single data stream by multiple devices
US10430210B2 (en) 2014-12-30 2019-10-01 Micron Technology, Inc. Systems and devices for accessing a state machine
US10592450B2 (en) 2016-10-20 2020-03-17 Micron Technology, Inc. Custom compute cores in integrated circuit devices
US10684983B2 (en) 2009-12-15 2020-06-16 Micron Technology, Inc. Multi-level hierarchical routing matrices for pattern-recognition processors
US10691964B2 (en) 2015-10-06 2020-06-23 Micron Technology, Inc. Methods and systems for event reporting
US10769099B2 (en) 2014-12-30 2020-09-08 Micron Technology, Inc. Devices for time division multiplexing of state machine engine signals
US10846103B2 (en) 2015-10-06 2020-11-24 Micron Technology, Inc. Methods and systems for representing processing resources
CN112130902A (zh) * 2020-09-11 2020-12-25 苏州浪潮智能科技有限公司 一种状态机控制方法、装置、设备及可读介质
US10929764B2 (en) 2016-10-20 2021-02-23 Micron Technology, Inc. Boolean satisfiability
US10977309B2 (en) 2015-10-06 2021-04-13 Micron Technology, Inc. Methods and systems for creating networks
US11023758B2 (en) 2009-01-07 2021-06-01 Micron Technology, Inc. Buses for pattern-recognition processors
US11366675B2 (en) 2014-12-30 2022-06-21 Micron Technology, Inc. Systems and devices for accessing a state machine

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5799193A (en) * 1996-04-29 1998-08-25 Siemens Corporate Research, Inc. Scenario based iterative method for development of an object oriented system model
US5867717A (en) * 1994-12-22 1999-02-02 Texas Instruments Incorporated Dynamic system clocking and address decode circuits, methods and systems
US5937202A (en) * 1993-02-11 1999-08-10 3-D Computing, Inc. High-speed, parallel, processor architecture for front-end electronics, based on a single type of ASIC, and method use thereof
US6119125A (en) * 1998-04-03 2000-09-12 Johnson Controls Technology Company Software components for a building automation system based on a standard object superclass

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5937202A (en) * 1993-02-11 1999-08-10 3-D Computing, Inc. High-speed, parallel, processor architecture for front-end electronics, based on a single type of ASIC, and method use thereof
US5867717A (en) * 1994-12-22 1999-02-02 Texas Instruments Incorporated Dynamic system clocking and address decode circuits, methods and systems
US5799193A (en) * 1996-04-29 1998-08-25 Siemens Corporate Research, Inc. Scenario based iterative method for development of an object oriented system model
US6119125A (en) * 1998-04-03 2000-09-12 Johnson Controls Technology Company Software components for a building automation system based on a standard object superclass

Cited By (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10838966B2 (en) 2008-12-01 2020-11-17 Micron Technology, Inc. Devices, systems, and methods to synchronize simultaneous DMA parallel processing of a single data stream by multiple devices
US10417236B2 (en) 2008-12-01 2019-09-17 Micron Technology, Inc. Devices, systems, and methods to synchronize simultaneous DMA parallel processing of a single data stream by multiple devices
US11023758B2 (en) 2009-01-07 2021-06-01 Micron Technology, Inc. Buses for pattern-recognition processors
US11768798B2 (en) 2009-12-15 2023-09-26 Micron Technology, Inc. Multi-level hierarchical routing matrices for pattern-recognition processors
US10684983B2 (en) 2009-12-15 2020-06-16 Micron Technology, Inc. Multi-level hierarchical routing matrices for pattern-recognition processors
US11226926B2 (en) 2009-12-15 2022-01-18 Micron Technology, Inc. Multi-level hierarchical routing matrices for pattern-recognition processors
WO2013190416A3 (fr) * 2012-06-23 2014-05-22 Pmda Services Pty Ltd Dispositif informatique permettant des transitions d'états d'automates à états finis récursifs et procédé informatisé permettant la définition, la conception et le déploiement d'automates à états finis récursifs adaptés au domaine et destinés à des dispositifs informatiques de ce type
US10831672B2 (en) 2012-07-18 2020-11-10 Micron Technology, Inc Memory management for a hierarchical memory system
US9524248B2 (en) 2012-07-18 2016-12-20 Micron Technology, Inc. Memory management for a hierarchical memory system
US10089242B2 (en) 2012-07-18 2018-10-02 Micron Technology, Inc. Memory management for a hierarchical memory system
WO2014035700A1 (fr) * 2012-08-31 2014-03-06 Micron Technology, Inc Insertion d'instructions dans des moteurs d'automate fini
US9934034B2 (en) 2012-08-31 2018-04-03 Micron Technology, Inc. Instruction insertion in state machine engines
US9063532B2 (en) 2012-08-31 2015-06-23 Micron Technology, Inc. Instruction insertion in state machine engines
US10067901B2 (en) 2013-03-15 2018-09-04 Micron Technology, Inc. Methods and apparatuses for providing data received by a state machine engine
US11775320B2 (en) 2013-03-15 2023-10-03 Micron Technology, Inc. Overflow detection and correction in state machine engines
US10606787B2 (en) 2013-03-15 2020-03-31 Mircron Technology, Inc. Methods and apparatuses for providing data received by a state machine engine
US9747242B2 (en) 2013-03-15 2017-08-29 Micron Technology, Inc. Methods and apparatuses for providing data received by a plurality of state machine engines
US10372653B2 (en) 2013-03-15 2019-08-06 Micron Technology, Inc. Apparatuses for providing data received by a state machine engine
US9448965B2 (en) 2013-03-15 2016-09-20 Micron Technology, Inc. Receiving data streams in parallel and providing a first portion of data to a first state machine engine and a second portion to a second state machine
US9703574B2 (en) 2013-03-15 2017-07-11 Micron Technology, Inc. Overflow detection and correction in state machine engines
US11016790B2 (en) 2013-03-15 2021-05-25 Micron Technology, Inc. Overflow detection and correction in state machine engines
US10929154B2 (en) 2013-03-15 2021-02-23 Micron Technology, Inc. Overflow detection and correction in state machine engines
US11366675B2 (en) 2014-12-30 2022-06-21 Micron Technology, Inc. Systems and devices for accessing a state machine
US10430210B2 (en) 2014-12-30 2019-10-01 Micron Technology, Inc. Systems and devices for accessing a state machine
US11580055B2 (en) 2014-12-30 2023-02-14 Micron Technology, Inc. Devices for time division multiplexing of state machine engine signals
US11947979B2 (en) 2014-12-30 2024-04-02 Micron Technology, Inc. Systems and devices for accessing a state machine
US10769099B2 (en) 2014-12-30 2020-09-08 Micron Technology, Inc. Devices for time division multiplexing of state machine engine signals
US10691964B2 (en) 2015-10-06 2020-06-23 Micron Technology, Inc. Methods and systems for event reporting
US10977309B2 (en) 2015-10-06 2021-04-13 Micron Technology, Inc. Methods and systems for creating networks
US10846103B2 (en) 2015-10-06 2020-11-24 Micron Technology, Inc. Methods and systems for representing processing resources
US11977902B2 (en) 2015-10-06 2024-05-07 Micron Technology, Inc. Methods and systems for event reporting
US11816493B2 (en) 2015-10-06 2023-11-14 Micron Technology, Inc. Methods and systems for representing processing resources
US10698697B2 (en) 2016-07-21 2020-06-30 Micron Technology, Inc. Adaptive routing to avoid non-repairable memory and logic defects on automata processor
US10146555B2 (en) 2016-07-21 2018-12-04 Micron Technology, Inc. Adaptive routing to avoid non-repairable memory and logic defects on automata processor
US10949290B2 (en) 2016-09-29 2021-03-16 Micron Technology, Inc. Validation of a symbol response memory
US10268602B2 (en) 2016-09-29 2019-04-23 Micron Technology, Inc. System and method for individual addressing
US10521366B2 (en) 2016-09-29 2019-12-31 Micron Technology, Inc. System and method for individual addressing
US10402265B2 (en) 2016-09-29 2019-09-03 Micron Technology, Inc. Validation of a symbol response memory
US10019311B2 (en) 2016-09-29 2018-07-10 Micron Technology, Inc. Validation of a symbol response memory
US10339071B2 (en) 2016-09-29 2019-07-02 Micron Technology, Inc. System and method for individual addressing
US10789182B2 (en) 2016-09-29 2020-09-29 Micron Technology, Inc. System and method for individual addressing
US10592450B2 (en) 2016-10-20 2020-03-17 Micron Technology, Inc. Custom compute cores in integrated circuit devices
US11194747B2 (en) 2016-10-20 2021-12-07 Micron Technology, Inc. Custom compute cores in integrated circuit devices
US10929764B2 (en) 2016-10-20 2021-02-23 Micron Technology, Inc. Boolean satisfiability
US11829311B2 (en) 2016-10-20 2023-11-28 Micron Technology, Inc. Custom compute cores in integrated circuit devices
US11478929B2 (en) 2016-11-09 2022-10-25 Abb Schweiz Ag Method for determining possible transitions of system states
CN109922930A (zh) * 2016-11-09 2019-06-21 Abb瑞士股份有限公司 用于确定系统状态的可能转换的方法
CN109922930B (zh) * 2016-11-09 2022-05-17 Abb瑞士股份有限公司 用于确定系统状态的可能转换的方法
WO2018086677A1 (fr) * 2016-11-09 2018-05-17 Abb Schweiz Ag Procédé de détermination de transitions possibles d'états de système
CN112130902A (zh) * 2020-09-11 2020-12-25 苏州浪潮智能科技有限公司 一种状态机控制方法、装置、设备及可读介质

Also Published As

Publication number Publication date
AU2574501A (en) 2001-06-04

Similar Documents

Publication Publication Date Title
WO2001038978A1 (fr) Pilote pour automate fini et methodes d'utilisation
CA2240194C (fr) Dispositif, systeme et procede de conception et de construction de composants et systemes logiciels en tant qu'ensembles de pieces independantes
Henning et al. Distributed programming with ice
US20030056205A1 (en) System of reusable software parts for event flow synchronization and desynchronization, and methods of use
US6505342B1 (en) System and method for functional testing of distributed, component-based software
US7984448B2 (en) Mechanism to support generic collective communication across a variety of programming models
EP1297428A2 (fr) Systeme et procede de conception a accent mis sur la coordination de systemes logiciels
JPH08504975A (ja) 分散型コンピュータシステムにおける遠隔手続き呼出しを実行するための方法およびシステム
WO2002027470A2 (fr) Parties reutilisables pour systemes logiciels assembles
US7523471B1 (en) Interpretive network daemon implemented by generic main object
Johnsen et al. Inheritance in the presence of asynchronous method calls
Jololian et al. A framework for a meta-semantic language for smart component-adapters
Taveira et al. Asynchronous Remote Method Invocation in Java.
Williamson et al. Concurrent communication and synchronization mechanisms
de Almeida Rust-based SOME/IP implementation for robust automotive software
König Using Interpreters for Scheduling Network Communication in Distributed Real-Time Systems
Kopysov et al. CORBA and MPI code coupling
Kaiserswerth Binding and run-time support for remote procedure call
Chen et al. Uncertainty update and dynamic search window for model-based object recognition
Parizek et al. Checking session-oriented interactions between web services
Frick D2. 1–Methodology for the Design of Distributed Embedded Systems under Special Requirements
EP1387263A2 (fr) Prodédé de conception et de construction de composants et systèmes logiciels en tant qu'ensembles de pieces independantes
Hendriks et al. The ToolBus: Introducing hierarchy, abstraction, namespaces and relays
Riedl et al. Dependable Distributed Start and Stop
Stubbs et al. IPCC++: a C++ extension for interprocess communication with objects

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase