The Mathworks, Inc.

Vijaya Raghavan

Ebrahim Mehran Mestchian

Srinath Avadhanula

Yao Ren

Ramamurthy Mani

Hidayet Tunc Simsek

Zhihong Zhao

Krishna Balasubramanian

John P Dirner

S M Shahed Nejhum

Jay Ryan Torgerson

Girish Venkataramani

Partha Biswas

Rama P Kokku

Chun-Yu Shei

Mahesh Nanjundappa

Jayaprabha Shankar

Siddhartha Shankar

James L Brock

Pieter Johannes Mosterman

John Edward Ciolfi

Peter S Szpak

Matthew J Englehart

David A Foti

Robert Olson Aberg

Michael David Tocci

Yit Phang Khoo

Shailesh Shashikant Nirgudkar

David B Andrade

Fazil Peermohammed

E Mehran Mestchian

Kalyan Bemalkhedkar

Alexander C Feinman

Nishith Aggarwal

Roy Mathew

Emmanuel Roy

Dekun Pei

Jianhao Du

Antoine Requet

Gregg P Smith

Vivek Bhownani

Yaohung Tsai

Alexander Feinman

Systems and methods generate code from a source program where the generated code may be compiled and executed on a Graphics Processing Unit (GPU). A parallel loop analysis check may be performed on regions of the source program identified for parallelization. One or more optimizations also may be applied to the source program that convert mathematical operations into a parallel form. The source program may be partitioned into segments for execution on a host and a device. Kernels may be created for the segments to be executed on the device. The size of the kernels may be determined, and memory transfers between the host and device may be optimized.

Systems and methods for generating code for parallel processing units

Systems and methods validate the operation of a component of an executable model without inadvertently altering the behavior of the component. The model may be partitioned into a design space and a verification space. The component may be placed in the design space, while an observer for validating the component may be placed in the verification space, and linked to the component. During execution of the model, input or output values for the component may be computed and buffered. Execution of the observer may follow execution of the component. The input or output values may be read out of the buffer, and utilized during execution of validation functionality defined for the observer. Model compilation operations that may inadvertently alter the behavior of the component, such as back propagation of attributes, are blocked between the observer and the component.

Observer for simulation test and verification

Processing external code includes: parsing the external code to identify a first semantic entity, mapping the first semantic entity to a second semantic entity, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified, determining that a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, determining available information for specifying the first attribute of the second set of one or more attributes, and storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on user selection or specifying the first attribute in response to available information provided to a user interface system.

External code integrations within a computing environment

A computing device may include a memory to store data that describes a state machine model that includes destination states and source states. The source states may be associated with conditions upon which the state machine model is to transition from a corresponding source state to one of the destination states. The device may also include a processor configured to generate data to describe a state diagram from the data that describes the state machine model. The state diagram may include the graphical symbols and lines. Each of the graphical symbols may represent one of the source states or one of the destination states. The lines may represent transitions and include one or more vertical lines to represent transitions to one of the destination states from more than one of the source states. The graphical symbol may represent the one of the destination states is not adjacent to the graphical symbols to represent the more than one of the source states. The processor may arrange graphical symbols in a first row, arrange lines, and arrange vertical lines in a second row that does not overlap with the first row.

Generating a state diagram

Systems and methods automatically construct a harness model having a selected component from source model. The systems and methods determine an execution context of the component in the source model, and construct and configure the harness model to provide the same or an equivalent execution context in the harness model. Model elements may be added to the harness model, and the model elements may be configured to replicate the execution context. The harness model may be executed, and the operation of the component evaluated. Changes to the component are synchronized between the source model and the harness model, as are changes to the component's execution context. Assessment operations may be included in the harness model, and these assessment operations may be evaluated when the harness model is executed. A verification report that includes the results of the assessments may be generated.

Systems and methods for creating harness models for model verification

Systems and methods may automatically generate code for deep learning networks. The systems methods may provide a code generation framework for generating target specific code. The code generation framework may include one or more predefined class hierarchies for constructing objects of the generated code. The objects of the class hierarchies may provide an interface to predefined libraries of deep learning functions optimized for use on a target platform. The systems and methods may perform one or more optimizations on the code being generated.

Systems and methods for automatically generating code for deep learning systems

A computer-readable memory device may include instructions to store data describing a state machine model including source states and destination states. The device may also include instructions to store, for each of the source states, a condition field identifying a condition upon which, when satisfied, the state machine model transitions from the source state to one of the destination states. The device may also include instructions to store, for each of source states, a destination field identifying the one of the destination states. Each of at least two of the source states may identify an identical destination state in the corresponding destination field. Each of at least two of the source states may identify an identical condition in the corresponding condition field.

Unified state transition table describing a state machine model

A system and method may generate executable models having message sending objects and message receiving objects. A message may include a fixed data payload, and the message may persist for only a determined time interval of a total execution or simulation time of model. Message queues may be established for the messages, and the queues may have attributes. The model may include a state-based portion having states and transitions. States may be configured to generate and send messages, and to receive and process messages. In addition, transitions may be guarded by particular messages. The system and method also may generate standalone code, such as source code, for the model. The standalone code may include code that establishes a message passing service to support the sending and receiving of messages.

Message-based modeling

A device receives information that identifies a model, of a finite state machine, that includes information that identifies a parent state and sub-states of the parent state. The device generates a data structure that designates an enumerated data type associated with the parent state, where the enumerated data type includes values corresponding to the sub-states. The device executes the model, based on the data structure, and monitors operation of the finite state machine and state transitions among some of the sub-states. The device detects, based on the state transitions, a change in an active sub-state that represents a particular sub-state, of the sub-states, that is active at a particular time during execution of the model. The device provides state transition information that identifies changes in the active sub-state over time.

Active state visualization for finite state machine models

A system and method provides top-down programming in a graphical programming environment. A developer may utilize a component constructor to create a graphical skeleton component that represents a template for a procedure. The graphical skeleton component may include one or more hole elements that mark locations in the component at which functions may be specified. An instance of the component may be included in a graphical model, and one or more functions specified for the hole elements, thereby completing the component. The one or more functions may refer to model parameters, and bindings may be captured among the parameters. Upon execution or simulation of the model, the one or more functions specified for the component are executed, and the parameters evaluated. The functionality of the completed may depend on the one or more functions specified for the hole elements.

Templatized component

A system and method may generate executable block diagrams in which at least some of the blocks run in accordance with message-based execution semantics. A message may include an input data payload that does not change over time, and the message may persist for only a determined time interval during execution of block diagram. A message-based execution engine may control execution of message-based blocks in which a source block may generate a message at a particular point in time, the message may be sent to one or more destination blocks triggering execution of those blocks, and the message may be destroyed on or after a determined time interval. Other execution domains, such as a time-based or state-based execution domain, may be provided, and the system may implement a hybrid execution model.

A system and method automatically inserts pipelines into a high-level program specification. An Intermediate Representation (IR) builder creates one or more graphs or trees based on the high-level program specification. A scheduler iteratively applies a bounded scheduling algorithm to produce an execution schedule for the IR minimizing overall execution time for a given number of pipeline stages. A Hardware Description Language (HDL) code generator may utilize the pipelined, scheduled IR to generate optimized HDL code corresponding to the high-level program specification. An annotated version of the high-level program specification showing where the pipelines have been inserted may be displayed allowing additional design exploration.

Auto pipeline insertion

A method of specifying a truth table includes generating a block diagram model, generating a statechart in the block diagram model, selecting a truth table graphical function in the statechart, and applying a set of graphical semantics for logic specification to the truth table graphical function combined with textual language predicates and actions.

System and method for using a truth table graphical function in a statechart

A system and method may generate executable block diagrams in which at least some of the blocks run in accordance with message-based execution semantics. A message may include an input data payload that does not change over time, and the message may persist for only a determined time interval during execution of block diagram. A message-based execution engine may control execution of message-based blocks in which a source block may generate a message at a particular point in time, the message may be sent to one or more destination blocks triggering execution of those blocks, and the message may be destroyed on or after a determined time interval. Other execution domains, such as a time-based or state-based execution domain, may be provided, and the system may implement a hybrid execution model. A verification engine may provide one or more tools for evaluating and verifying operation of message-based blocks. The verification engine may support one or more verification blocks that may be added to the block diagram and associated with the diagram's message-based blocks. The verification blocks may capture and present messages exchanged among the message-based blocks. The verification blocks may also specify an expected interaction of messages, and determine whether the actual messages are equivalent to the expected interaction. If not, the verification block may perform one or more predefined actions, such as suspending further execution of the block diagram.

Growing community of inventors

Brookline, MA, United States of America

Vijaya Raghavan