The Mathworks, Inc.

David H Koh

Murat Belge

Pieter Johannes Mosterman

Zijad Galijasevic

Donald Paul Orofino, Ii

Brian Keith Ogilvie

Justyna Zander

James K Weixel

Gautam K Vallabha

Shi Chao Zhang

Zhongxin Li

Jihad E Ibrahim

Xianchao Long

Ying-On Yan

Jerome O Chevalier

Tao Jia

Mazen Kachmar

Mary Ann Nazario

A device may connect to a physical device. A device may obtain a device description document relating to the physical device based on connecting to the physical device. The device may parse the device description document to identify one or more components of the physical device. The device may select, from a repository of generic textual model components, one or more generic textual model components corresponding to the physical device based on parsing the device description. The device may generate, based on selecting the one or more generic textual model components, a device driver model element that includes the one or more generic textual model components. The device driver model element may be used to control the physical device or receive information from the physical device. The device may provide, via a user interface, information identifying the device driver model element.

Component-based framework for generating device driver model elements

A device generates a block for a model associated with a system, and the system is associated with middleware. The block subscribes to information generated by the middleware based on communication between the middleware and the system. The device receives subscriber configuration information for configuring the block, and creates, based on the subscriber configuration information, a signal that converts the information generated by the middleware into a format compatible with the model.

Exchanging information among system middleware and models

A method may include establishing a connection with a physical device, by a device. The method may include receiving information identifying the physical device, by the device. The method may include determining physical device information based on receiving the information identifying the physical device, by the device. The physical device information may be a description of the physical device. The method may include generating a set of model elements based on the physical device information, by the device. The set of model elements may include program code associated with simulating a behavior associated with the physical device. The method may include associating the set of model elements with a device model corresponding to the physical device, by the device.

Automatic generation of models from detected hardware

A system and method automatically generates graphical model from an object-oriented, textual program, and verifies the performance of the graphical model to the textual program. The textual program may include a plurality of system objects having properties. The objects may be mapped to graphical model blocks that have parameters. The properties of the system objects may be mapped to the parameters of the graphical model blocks.

System and method for automatically generating a graphical model from a text-based program

A device may receive model information that describes a model and external system information that describes an external system that is different than the model. The model information may identify a first set of signals, associated with the model, that are incompatible with the external system. The external system information may identify a second set of signals, associated with the external system, that are incompatible with the model. The device may generate interface code based on the model information and the external system information. The interface code, when executed, may permit the model and the external system to interact using the first set of signals and the second set of signals. The device may execute the interface code to transform the first set of signals to the second set of signals and to transform the second set of signals to the first set of signals.

Generation of an interface for interaction between a modeling environment and an external system

A device may receive information specifying a physical time delay of a computational node of a first computational graph. The first computational graph may include a group of computational nodes that are connected in a particular manner, and may represent at least a portion of a dynamic system. The device may further add an abstract node to a second computational graph based on the received information. The abstract node may correspond to the computational node and may implement the physical time delay when the second computational graph is executed. The second computational graph may include a group of abstract nodes that are connected in the particular manner. The device may also execute the second computational graph, and may obtain one or more behavioral characteristics of the at least the portion of the dynamic system based on executing the second computational graph.

Using abstract nodes to test the behavior of a dynamic system

A method may include receiving, by a device, information associated with a model. The method may include determining, by the device, performance criteria for program code generated based on the model. The method may include determining, by the device, profiling information associated with the program code. The method may include determining, by the device and based on the profiling information, that the performance criteria is not satisfied. The method may include applying, by the device and based on determining that the performance criteria is not satisfied, a modification technique to a portion of the model to create a modified model. The modification technique may be applied to the portion of the model to cause program code, generated based on the modified model, to satisfy the performance criteria.

Modifying models based on profiling information

In an embodiment, a method for interactively changing allocation of an application including multiple algorithm components executing on a heterogeneous target environment (HTE) provides a user interface in a co-simulation design environment. The user interface is associated with the application having multiple algorithm components executing on the HTE that includes multiple computing devices with different processing capabilities. The method also sets attributes of the allocation scheme of the application using the user interface. The setting occurs when the application is executing. The method further receives data associated with the executing of the application in the co-simulation design environment when the application is executing subsequent to the setting of the attributes of the allocation scheme.

Interactive partitioning and mapping of an application across multiple heterogeneous computational devices from a co-simulation design environment

The present invention provides a set of blocks for creating device drivers. Since, for most computational devices, device driver code to configure and control an I/O interface may be decomposed into a small finite number of common software functions, by providing a block set comprising blocks representing the finite number of common software functions, custom device drivers can be created for any number of devices. Thus, by providing a set of generalized device driver blocks that can be parameterized by the user, specific instances of custom device drivers can be created as needed. Processor and device specific driver code can then be generated from the custom device driver.

Graphical programming of custom device drivers

The present invention provides a method and system for automatic verification of automatically generated standalone code intended for execution on a target computing platform against its original design simulated in a simulation environment. The present invention also applies to execution comparisons between two implementations, such as two simulations, one simulation and one standalone code implementation, or two standalone code implementations. Block diagrams can be used to create a comparison model that compares two implementations. The comparison of different implementations can be performed at a block level, a subsystem level, a model level, or multi-model level. The present invention allows automatic comparison once a user supplies the intermediate outputs and/or signals that the user wants to compare and monitor. Reports can be generated to show the statistics of the comparison results.

Automatic comparison and performance analysis between different implementations

In an embodiment, a method for interactively varying scheduling of a multi-threaded application executing on a symmetric multi-core processor provides an interface in a co-simulation design environment. The interface is associated with a multi-threaded application executing on a target processor that includes symmetric processor cores. The method also sets a scheduling attribute of the multi-threaded application using the interface. The setting occurs when the multi-threaded application is executing. The method further receives data associated with the executing of the multi-threaded application in the co-simulation design environment when the multi-threaded application is executing subsequent to the setting of the scheduling attribute.

Interactive scheduling of an application on a multi-core target processor from a co-simulation design environment

A device generates code with a technical computing environment (TCE) based on a model and information associated with a target processor, registers an algorithm with the TCE, automatically sets optimization parameters applied during generation of the code based on the algorithm, executes the generated code, receives feedback based on execution of the generated code, and uses the feedback to automatically update the optimization parameters and to automatically regenerate the code with the TCE until an optimal code is achieved for the target processor.

Growing community of inventors

Boston, MA, United States of America

David H Koh