Scheduling generated code based on target characteristics

[0001] Graphical models may be used to simulate types of physical systems, such as discrete systems, event-based systems, time-based systems, state-based systems, data flow-based systems, etc. These models may include components, such as blocks, that reference executable code for performing operations when the graphical model is executing. The blocks can vary in type and/or number and may be connected together to build large, complex models (e.g., models including hundreds or more interconnected blocks).

[0002] At times, it may be desirable to implement code from some or all of a graphical model on a target platform once a model has been designed. For example, a user may develop a graphical model on a workstation. When the model is complete, the user may wish to execute the model on a target device that includes a real-time operating system. In this example, the model may need to execute within a determined time interval on the target so that the target can perform processing operations in real-time (e.g., processing data from a running system without falling behind over time).

[0003] The user may need to perform trial and error guesses regarding how to schedule various components of the model for real-time execution on the target. For example, the target may utilize two processors to perform real-time processing. The user may need to allocate a portion of the model components to execute on one processor and another portion of the components to execute on the other processor. If the target cannot operate in real-time with this configuration, the user may need to reallocate the components in a different way and then determine whether the new configuration will execute in real-time on the target.

[0004] In some instances the user may spend significant time attempting different configurations in order to arrive at a schedule configuration amenable to real-time execution on the target. In some instances, such as when a model contains many components, the user may be unable to identify a schedule configuration for the model components that allows for real-time execution on the target. This last situation may frequently occur when, for example, some model components rely on other model components for data, or where model components have differing operating priorities in the model.

[0029] The following detailed description of implementations consistent with principles of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and their equivalents.

[0030] Executable graphical models may be deployed to a target in order to have the target perform certain operations. At times, it may be desirable to have the target perform operations according to certain constraints, such as a real-time execution constraint. Real-time may refer to a requirement for speed of execution or a response to an external event. For example, a real-time processor may need to execute code within a determined time interval, where the interval identifies a boundary of what is considered real-time. Alternatively, a real-time processor may need to process an input signal within the determined interval that identifies the real-time boundary. If the real-time processor cannot process code or respond to an event within the determined interval, the processor may be considered to no longer be processing in real-time (e.g., when the processor fails to execute code within the real-time interval or within a memory usage constraint, which may cause processing results to become progressively more delayed as the processor continues to operate).

[0031] In many applications, the target will include two or more types of processing logic for performing real-time processing. For example, the target may include two or more processors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific instruction-set processors (ASIPs), digital signal processors (DSPs), graphics processor units (GPUs), programmable logic devices (PLDs), etc. Alternatively, the target may include a single processor that includes two or more types of logic, such as cores. The target may further use one or more threads, processes, or tasks with processing logic to perform real-time processing.

[0032] When a user wishes to run a model on the target, the number and types of processing logic on the target may be taken into account. In addition, other characteristics of the target may need to be accounted for, such as memory size/type, clock rates, bus speeds, network connections, operating system type, etc. Other characteristics that can be taken into account include, but are not limited to, whether the target supports execution priorities, single-tasking execution, multi-tasking execution, preemption, time slicing, concurrency, etc. When a model is transformed into a format for real-time execution on the target, such as by generating executable code from the model, components in the model may need to be scheduled for execution on types of processing logic in the target. For example, code for model components may be temporally related to each other and scheduling the code for the components may need to account for this relationship to satisfy a real-time constraint.

[0033] Exemplary embodiments account for target characteristics when generating code from a graphical model. For example, an embodiment may receive information about target characteristics from the target via a link. The embodiment may use the information to determine whether a schedule received from a user will allow a graphical model, or parts of the model, to execute in real-time on the target. The embodiment may allow the user to select a different schedule or may provide the user with a programmatically generated schedule that will support real-time execution on the target. In this example, the user is provided with feedback about an execution schedule without having to generate code from the model and without having to execute the generated code on the target to determine whether the code will execute in real-time.

[0034] Exemplary embodiments can further optimize generated code based on target characteristics to ensure that generated code executes in real-time on the target. Exemplary embodiments can also provide a user with interactive reports that allow the user to enter selections regarding target characteristics, model components, simulation environments, etc. Exemplary embodiments can further be used in local configurations (e.g., where target hardware is plugged into a device that performs modeling and code generation) or remote configurations where one or more targets are remote with respect to a device that performs modeling and code generation. Exemplary embodiments can further be used with multiple target environments that operate collectively in a computing grid or other arrangement to perform parallel real-time processing.

[0035] FIG. 1 illustrates an exemplary system 100 for practicing an embodiment. For example, system 100 may be used to construct a model that includes one or more components and to generate code for the model based on target characteristics received from a target environment. For example, an embodiment can receive target characteristics directly from the target environment, or indirectly from the target environment (e.g., from another device on behalf of the target environment). System 100 may include computer 110, target environment 130 and network 160. The system in FIG. 1 is illustrative and other embodiments of system 100 can include fewer devices, more devices, and/or devices in configurations that differ from the configuration of FIG. 1.

[0036] Computer 110 may include a device that performs processing operations, display operations, communication operations, etc. For example, computer 110 may include logic, such as one or more processing or storage, devices that can be used to perform and/or support processing activities on behalf of a user. Embodiments of computer 110 may include a desktop computer, a laptop computer, a client, a server, a mainframe, a personal digital assistant (PDA), a web-enabled cellular telephone, a smart phone, smart sensor/actuator, or another computation or communication device that executes instructions to perform one or more activities and/or to generate one or more results.

[0037] Computer 110 may further perform communication operations by sending data to or receiving data from another device, such as target environment 130. Data may refer to any type of machine-readable information having substantially any format that may be adapted for use in one or more networks and/or with one or more devices. Data may include digital information or analog information. Data may further be packetized and/or non-packetized.

[0038] Computer 110 may include operating system 115, simulation environment 120, and input device 125. Operating system 115 may include logic that manages hardware and/or software resources associated with computer 110. For example, operating system 115 may manage tasks associated with receiving user inputs, operating computing environment 110, allocating memory, prioritizing system requests, etc. In an embodiment, operating system 115 may be a virtual operating system. Embodiments of operating system 115 may include Linux, Mac OS, Microsoft Windows, Solaris, UNIX, etc. Operating system 115 may further support virtualization.

[0039] Simulation environment 120 includes logic that provides a computing environment that allows users to perform simulation or modeling tasks related to disciplines, such as, but not limited to, mathematics, science, engineering, medicine, business, etc. Simulation environment 120 may support one or more applications that execute instructions to allow a user to construct an executable model and to execute the model to produce a result. Simulation environment 120 may be configured to receive target characteristics from target environment 130 and may generate code from a model based on the target characteristics. Simulation environment 120 may send generated code to target environment 130 via network 160 so that target environment 130 can execute the code to produce a result. While the embodiment of FIG. 1 includes a simulation environment 120, other embodiments may be implemented without a simulation environment.

[0040] Input device 125 may include logic to receive user inputs. For example, input device 125 may transform a user motion or action into a signal or message that can be interpreted by computer 110. Input device 125 can include, but is not limited to, keyboards, pointing devices, biometric devices, accelerometers, microphones, haptic devices, etc.

[0041] Target environment 130 may include logic that executes instructions to perform one or more operations. In an embodiment, target environment 130 can include processing logic adapted to execute generated code received from computer 110. In an embodiment, target environment 130 can include real-time logic for performing processing operations in real-time. For example, target environment 130 may include a real-time operating system and hardware that are configured to process received signals or events in real-time or to execute simulations in real-time.

[0042] In an embodiment, target environment 130 may include real-time operating system 135 (RT-O/S 135) and real-time logic 140 for performing real-time computing operations. RT-O/S 135 may include software that manages hardware and/or software resources associated with target environment 130. For example, RT O/S 135 may be a multitasking operating system that supports real-time operations in target environment 130. These real-time operations can include, but are not limited to, receiving information, such as executable code, from computer 110; controlling hardware that acquires real-time data, real-time processing of acquired data, buffering real-time data during processing, storing processed real-time data, displaying results of real-time processing, controlling actuator hardware, etc.

[0043] Real-time logic 140 may include hardware that supports real-time tasks in target environment 130. For example, real-time logic 140 may perform receiving, processing, buffering, storing, transmitting, etc., operations in target environment 130. For example, real-time logic 140 may include one or more specialized processing devices for processing real-time data, random access memories (RAMs) for storing processed real-time data, and communication mechanisms for transferring information between real-time logic 140 and RT-O/S 135. Embodiments of real-time logic 140 can include one or more cores 150, e.g., cores 150-1 to 150-N, for processing instructions associated with a real-time operation.

[0044] Network 160 may include a network that transfers data (e.g., packet data or non-packet data). Implementations of network 160 may include local area networks (LANs), metropolitan area networks (MANs) and/or wide area networks (WANs), such as the Internet, that may operate using substantially any network protocol, such as Internet protocol (IP), asynchronous transfer mode (ATM), synchronous optical network (SONET), user datagram protocol (UDP), IEEE 802.11, Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, etc.

[0045] Network 160 may include network devices, such as routers, switches, firewalls, and/or servers (not shown). Network 160 may be a hardwired network using wired conductors and/or optical fibers and/or may be a wireless network using free-space optical, radio frequency (RF), and/or acoustic transmission paths. In one implementation, network 160 may be a substantially open public network, such as the Internet. In another implementation, network 160 may be a more restricted network, such as a corporate virtual network. Implementations of networks and/or devices operating on networks described herein are not limited to any particular data type, protocol, architecture, configuration, etc.

[0046] FIG. 2 illustrates an exemplary embodiment of a simulation environment 120. Simulation environment 120 can include simulation tool 210, component library 220, interface logic 230, compiler 240, scheduler 250, optimizer 260, simulation engine 270, report engine 280, and code generator 290. The embodiment of simulation environment 120 illustrated in FIG. 2 is illustrative and other embodiments of simulation environment 120 can include more entities or fewer entities without departing from the spirit of the invention.

[0047] Simulation tool 210 may be an application for building an executable model, such as a graphical model. Simulation tool 210 may allow users to create, modify, diagnose, delete, etc., model components and/or connections. Simulation tool 210 may interact with other entities illustrated in FIG. 1 or 2 for receiving user inputs, executing a model, displaying results, interacting with target characteristics, etc.

[0048] Component library 220 may include components, e.g., blocks/icons, and/or connections (e.g., lines) that a user can drag and drop into a display window representing a graphical model. The user may further connect components using connections to produce an executable graphical model.

[0049] Interface logic 230 may allow simulation environment 120 to send or receive data and/or information to/from devices (e.g., target environment 130) or software modules (e.g., an application program interface). Compiler 240 may compile a model into an executable format. In an embodiment, compiler 240 may provide a user with debugging capabilities for diagnosing errors associated with the model. Compiled code produced by compiler 240 may be executed on computer 110 to produce a modeling result.

[0050] Scheduler 250 may schedule execution of model components on various types of processing logic, such as a microprocessor, a core, an FPGA, an ASIC, etc. Embodiments of scheduler 250 may implement substantially any type of scheduling technique, such as single-rate scheduling, multi-rate scheduling, round-robin scheduling, time-slicing scheduling, preemption, etc. In an embodiment, scheduler 250 may use target characteristics to determine how to schedule components in a model for execution on computer 110 and/or target environment 130. For example, scheduler 250 may schedule model components to be distributed and executed on certain real-time processors, or cores, so that the model components execute within a determined time interval (e.g., a real-time execution interval). In an embodiment, scheduler 250 can include an analysis engine for evaluating model components to determine scheduling information related to the components.

[0051] Optimizer 260 may optimize code for a model based on a parameter. For example, optimizer 260 may optimize code to cause the code to occupy less memory, to cause the code to execute more efficiently, to cause the code to execute faster, etc., than the code would if the code were not optimized. In an embodiment, optimizer 260 may operate with or may be integrated into compiler 240, scheduler 250, code generator 290, etc.

[0052] Simulation engine 270 may execute code for a model to simulate a system. For example, simulation engine 270 may receive compiled code from compiler 240 and may execute the code to produce a modeling result. Simulation engine 270 may be configured to perform standalone or remote simulations based on user preferences or system preferences.

[0053] Report engine 280 may produce a report based on information in simulation environment 120. For example, a user may build a model and then may desire to generate code from the model, where the generated code will execute on target environment 130. Report engine 280 may display an interactive report to the user that shows the user available real-time logic 140 along with model components that will execute on respective ones of the real-time logic. The user may select certain blocks to run on a first core 150-1 of real-time logic 150 and the remainder of the blocks to run on a second core 150-N. Once the user has made selections, simulation environment 120 may perform simulation and/or scheduling operations to determine whether the configuration input by the user will execute within a determined time interval (e.g., a real-time interval on target environment 130). Embodiments of report engine 280 can also produce reports in a hardcopy format or a format adapted for storage in a storage device.

[0054] Code generator 290 can generate code from a model. In an embodiment, code generator 290 may receive code in a first format and may transform the code from the first format into a second format. In an embodiment, code generator 290 can generate source code, assembly language code, binary code, interface information, configuration information, performance information, etc., from at least a portion of a graphical model.

[0055] For example, code generator 290 can generate C, C++, SystemC, Java, etc., from the graphical model. Embodiments of code generator 290 can further generate Unified Modeling Language (UML) based representations and/or extensions from some or all of a graphical model (e.g., System Modeling Language (SysML), Extensible Markup Language (XML), Modeling and Analysis of Real Time and Embedded Systems (MARTE), Hardware Description Language (HDL), Automotive Open System Architecture (AUTOSAR), etc.).

[0056] Scheduler 250 may support a number of scheduling methodologies that can be implemented on one or more types of processing logic. For example, scheduler 250 can support single-tasking or multi-tasking scheduling modes.

[0057] FIGS. 3A and 3B illustrate an exemplary implementation of single-tasking scheduling for code segments. Code for a model may be made up of units, such as segments, that collectively make up the model. For example, one code segment may implement a first block, function, etc., and a second code segment may implement a second block, function, etc. These code segments may be related to each other, e.g., in time (temporally), and may execute according to a simulation schedule when the model is executed.

[0058] Referring to FIG. 3A, code making up a model may include 1 millisecond (ms) segment 310, 2 ms segment 320, and 4 ms segment 330. In FIG. 3A, 1 ms segment 310 may execute every 1 ms, 2 ms segment 320 may execute every 2 ms, and 4 ms segment 330 may execute every 4 ms when a model that includes segments 310, 320 and 330 executes properly, e.g., executes within a determined time interval. In the single-tasking implementation of FIG. 3A, the sampling interval 340 of the model is 1 ms. Therefore, each segment of code needs to start and stop executing within 1 ms for a model to execute properly.

[0059] In FIG. 3A, segment 310, 320 and 330 each execute between t₀ and t₁. Then segment 310 executes again at t₁, t₂, t₃, t₄ and t₅ since this code segment executes every 1 ms. During the interval t₂-t₃, segment 320 executes since this code segment executes every 2 ms. During the interval t₃₄₄, only segment 310 executes. And, during the interval t₄-t₅, segments 310, 320 and 330 execute. In FIG. 3A, the model executes as desired since segments 310, 320, and 330 all execute within a 1 ms sampling interval 340.

[0060] In contrast to FIG. 3A, FIG. 3B illustrates a situation in which the model does not execute as desired because one or more code segments 310, 320 and 330 do not finish executing within interval 340. For example, at t₁, code segment 330 did not finish executing during interval t₀-t₁. Execution of code segment 330 can be said to have overrun interval t₀-t₁, spilling over into interval t₁-t₂.

[0061] In FIG. 3B, an overrun occurs at t5 when code segment 320 does not finish executing during interval t₄-t₅. Since overruns occur in FIG. 3B, the model does not execute as desired. If the model of FIGS. 3A and 3B were designed to run in real-time, the implementation of FIG. 3A may satisfy the real-time constraint for the model. However, the implementation of FIG. 3B would not satisfy the real-time constraint since overruns occur during execution. In FIG. 3B the model may crash, issue an error, or may fall further and further behind in time as the model continues to execute. Alternatively, the model may incidentally fall behind real time, but may catch up during intervals when less code is executed. These temporary overruns may result in soft real-time behavior, and this may be allowed in certain applications.

[0062] Models may also use multi-tasking scheduling modes for execution. In situations where multi-tasking is used, a user may find it more difficult to determine how to schedule code segments since techniques, such as preemption, can be used to interrupt execution of certain code segments in order to let other code segments execute. For example, code segments may have execution priorities associated with them. A low priority code segment may be executing and its execution may not end before the beginning of a next sampling interval. Instead of overrunning into the next sampling interval, as might happen in single-tasking scheduling, the low priority code segment may be paused, or preempted, to allow a higher priority code segment to execute. When the higher priority code segment has executed, the low priority code segment may finish executing.

[0063] FIG. 4 illustrates an exemplary implementation of multi-tasking scheduling for code segments. FIG. 4 utilizes segments 310, 320, and 330 from FIGS. 3A and 3B and further utilizes a sampling interval of 1 ms. In FIG. 4, code segment 310 may have a priority that is higher than a priority of code segment 320, and code segment 320 may be of a higher priority than a priority of code segment 330.

[0064] Referring to FIG. 4, 1 ms segment 310 may start executing at t₀ (as shown on trace 402) and 2 ms segment 320 may begin executing after t₀ but during the interval t₀-t₁ (as shown on trace 404). Segment 320 may not finish executing before time t₁. Since segment 320 has a priority that is lower than a priority of segment 310, execution of segment 320 may be preempted at t₁ so that segment 310 can execute a second time. When segment 310 finishes executing during the interval t₁-t₂, segment 320 resumes executing.

[0065] During interval t₁-t₂, code segment 330 may begin executing (as shown on trace 406). At t₂, execution of segment 330 may be preempted so that segment 310 can execute and so that segment 320 can begin executing during interval t₂-t₃. Segment 330 may resume executing once higher priority segments have finished executing, such as segments 310 and 320.

[0066] FIGS. 5A and 5B illustrate views for an exemplary model that includes blocks having relationships therebetween. These relationships may contain a scheduling aspect. Exemplary embodiments may display information to a user via a graphical user interface, such as graphical model 510 (hereinafter model 510). In an embodiment, model 510 may be implemented using simulation tool 210. Information can be displayed using a variety of techniques without departing from the spirit of the invention. For example, as illustrated in FIG. 5A, model 510 may display blocks 520, 530, 540 and 550, where the blocks represent executable code segments. In addition, model 510 may represent connections between blocks using line 560. In an embodiment, line 560 may include directionality information, such as arrow heads, text, icons, etc., and in another embodiment, line 560 may not include directionality information. The line may represent for example, data shared between the blocks, invocation of a block or a code segment such as a function or method call, etc.

[0067] In an embodiment, such as that of FIG. 5A, blocks 520-550 may have the same or similar shapes. For example, all blocks may be represented using a square or rectangle where the all squares or rectangles are the same size and/or color. Embodiments of model 510 may also display blocks in a way where the size, shape, color, shading, etc., of a block is representative of characteristics of the block.

[0068] For example, referring to FIG. 5B, model 510 may represent blocks using visual characteristics that represent: a size or amount of code making up the block, an execution rate for the block (e.g., once every 1 ms, 2 ms, etc.), an execution time (e.g., a number of milliseconds it should take to execute a block), etc. In FIG. 5B, the sizes of blocks 520A, 530A, 540A, and 550A may represent the amount of time that it takes a respective block to execute. In an embodiment, the time it takes for a respective block to execute can be an estimated time, a computed time, a profiled time, etc. In addition, the times may be representative of best case execution times, worst case execution times, average execution times, median execution times, worst case response times, best case response times, etc. For example, block 520A may take longer to execute than block 530A because, for example, block 520A is longer (wider) than block 530A. Fill patterns or any other graphical representation such as, for example, color, of blocks in FIG. 5B may also be used to convey information about characteristics of blocks, such as information about a priority of a block, execution time for a block, data dependencies associated with a block, etc.

[0069] Line 560 may represent connections between blocks and may show information about data flows and/or dependencies (e.g., an arrowhead may indicate a direction of data flow and may indicate that block 550A takes as input data from blocks 520A, 530A, and 540A and may derive a data and/or an execution dependency from that). In FIG. 5B, the location of blocks within model 510 may convey information such as when a block executes relative to a time reference and/or to execution of another block. For example, reference line 517 may represent a time axis and reference line 515 may indicate execution priorities of blocks making up model 510. Lines, such as line 560, may also be used to convey time information in model 510. For example, line 560 may connect to block 550A at a point somewhere along the top edge of the rectangle of block 550A. The location of the connection may indicate when, during model execution, data is available for output or available for use as input.

[0070] A user of model 510 may desire to generate code from the model, such as generated code adapted to execute in target environment 130. Proper execution of the generated code may require that code segments included in the generated code execute according to a schedule.

[0071] By way of example, assume that target environment 130 is a real-time target that needs to respond to external events within a determined interval (e.g., within 1 ms) in order to sustain real-time processing of the events. Maintaining real-time execution over time may require that code segments execute according to a real-time schedule (e.g., a real-time single-tasking schedule or multi-tasking schedule). Continuing with the example, target environment 130 may include concurrent resources such as real-time logic 140 having two cores, 150-1 and 150-2.

[0072] Referring to FIG. 6A and continuing with the example, the user may assign a first subset of the blocks in model 510 into a first collection 615 for execution on core 150-1 and may assign a second subset of the blocks in model 510 into a second collection 625 for execution on core 150-2. In an embodiment, first collection 615 may be identified using a first border 610 and second collection 625 may be defined using a second border 620. Borders used with embodiments may use substantially any technique for identifying one or more executable graphical icons as belonging to a group (e.g., a line, a shape, shading, intermittent on/off display, audio signals, annotations, markers, tags, block parameters, etc.)

[0073] Still continuing with the example, generated code for target environment 130 may be configured according to the user's selection. Namely, generated code for blocks 520A and 550A may be configured to execute on core 150-1 and generated code for blocks 530A and 540A may be configured to execute on core 150-2. In an embodiment, the user may execute the generated code on target environment 130 to determine whether the generated code executes as desired, or simulation tool 210 may determine whether the schedule identified by the user (i.e., the schedule reflected in first collection 615 and second collection 625 of blocks) will execute as desired when implemented on target environment 130.

[0074] Still continuing with the example, the user may be provided with information that indicates that the schedule reflected in first collection 615 and second collection 625 will not execute fast enough to support real-time execution because of overruns, because of repeated overruns that violate soft real-time constraints, and/or unacceptable waiting times for core 150-1 and/or 150-2.

[0075] For example, referring to FIG. 6B, the user may be presented with a display that includes trace 622 and trace 624. Traces 622 and 624 may display information about segments of code that execute on core 150-1 or 150-2, respectively. Traces 622 and 624 may indicate that segment 520A executes during interval t₀-t₁ on core 150-1 and that segment 530A executes during t₀-t₁ on core 150-2. Traces 622/624 may also indicate that segment 550A begins to execute during interval t₀-t₁ but is paused or preempted during interval t₀-t₁ (as indicated by wait interval 630) so that segment 540A can finish executing. Segment 550A may need to wait for segment 540A to finish executing because segment 550A needs data from segment 540A to completely perform its processing activities. The failure of segment 550A to finish executing during interval t₀-t₁ may cause an overrun 640 during interval t₁-t₂. Overrun 640 may cause target environment 130 to produce processing results in non-real-time, i.e., target environment 130 may not generate results within a real-time interval in response to an external event.

[0076] Referring now to FIG. 7A, in an embodiment, the user may interact with model 510 and may re-group blocks of model 510 into an updated first collection 715 and an updated second collection 725. The updated collections 715, 725 may be identified, respectively, using updated border 710 and 720. In FIG. 7A, the updated collections 715, 725 may reflect updated schedules for blocks making up model 510 when code is generated for core 150-1 and 150-2. In another embodiment, computer 110 may programmatically determine collections 715 and 725 and may display borders 710 and 720 to identify the determined collections without requiring user inputs.

[0077] When the updated schedule is determined to be satisfactory, computer 110 may generate code for core 150-1 and 150-2 according to the updated collections 715 and 725. In an embodiment, the user may be presented with the display illustrated in FIG. 7B when the generated code is evaluated for operation on target environment 130 using the updated schedule. In an embodiment, the user may be presented with the display of FIG. 7B before any code is generated and/or executed on target environment 130.

[0078] Referring to FIG. 7B, code segments may be scheduled on cores 150-1 and 150-2 based on an updated schedule that accounts for updated collections 715 and 725. The configuration illustrated in FIG. 7B reduces wait interval 730 on trace 722 as compared to wait interval 630 on trace 622 of FIG. 6B. In FIG. 7B, the reduced wait interval 730 helps eliminate overrun 640 of FIG. 6B. The configuration of FIG. 7B may allow target environment 130 to operate according to real-time constraints when processing external events using cores 150-1 and 150-2.

[0079] Embodiments of system 100 may display information to a user using a number of techniques. In one embodiment, information may be displayed to a user via a graphical user interface and/or via an interactive report.

[0080] FIGS. 8A-8C illustrate exemplary user interfaces that can be used with embodiments. A user may wish to configure system 100 before performing modeling activities, scheduling activities, code generating activities, etc. In an embodiment, display 800 may be provided to a user to allow the user to configure system 100.

[0081] Display 800 may include window identifier 805, target identifier 810, target configuration 815, processing logic identifier 820 and 825 and output identifier 830. Window identifier 805 may identify to what information in display 800 pertains. For example, display 800 may pertain to setup activities for configuring system 100 to generate code for target environment 130.

[0082] Target identifier 810 may identify target environment 130. Target identifier 810 may identify target environment 130 using a name, address (e.g., network address), or other type of identifier. Target configuration 815 may identify configuration information about target environment 130. For example, computer 110 may use information provided for target identifier 810 to establish a connection with target environment 130 over network 160. Computer 110 may query target environment 130 and may obtain information that identifies how target environment 130 is configured. For example, the obtained information may indicate that target environment 130 includes an ACME RT-100 real-time processor that includes two cores. The target may be available as hardware or it may be emulated. For example, an instruction-set simulator may be available to execute generated code.

[0083] Processing logic identifier 820 and 825 may identify information about processing logic identified in target configuration 815. For example, processing logic identifier 820 may indicate which blocks of a model are executed on the first core of target environment 130 and processing logic identifier 825 may indicate which blocks of the model are executed on the second core of target environment 130. Output identifier 830 may identify a file name, storage location, etc., to which information about target environment 130, a model for use on target environment 130, or the contents of display 800 is stored.

[0084] FIG. 8B illustrates a user interface that can be used to display information about a schedule for executable code. For example, the user may enter information about target environment 130 using display 800 and computer 110 may perform processing operations in response to the inputs. Computer 110 may provide results of the processing to the user via display 802 of FIG. 8B. In an embodiment, computer 110 may have performed processing related to determining a schedule for code segments in generated code adapted to execute on target environment 130. Results of this processing may be displayed using display 802.

[0085] In FIG. 8B, display 802 may include a target identifier 810, window identifier 835, configuration identifier 850, results region 855, recommendation region 860, estimated processing time 870, and rerun button 880. Window identifier 835 may indicate to the user that information in display 802 is related to a report describing an expected performance of target environment 130 when executing code generated from a model. Target identifier 810 may identify target environment 130 and configuration identifier 850 may identify a particular hardware and/or software configuration for target environment 130 that was evaluated by computer 110. For example, information in configuration identifier may specify a type of: processing logic, real-time operating system, virtualization scheme, memory configuration, bus configuration, target environment scheduling, etc., in use or that will be in use on target environment 130 when generated code is executed.

[0086] Results region 855 may include information that identifies outcomes or results of processing performed by computer 110 on behalf of target environment 130 or that was performed by target environment 130 using the configuration identified in configuration identifier 850. For example, results region 855 may indicate: that core #1 incurred a waiting interval because of a data dependency issue for one or more blocks in a model, that core #1 sustained a data overrun for one or more blocks executing on core #1, that a total processing time for core #1 was 100 ms, etc.

[0087] Recommendation region 860 may include information about a configuration that differs from a configuration that was analyzed to determine whether target environment 130 could operate according to a constraint. For example, computer 110 may programmatically determine that blocks making up a model can be grouped into updated collections, where the updated collections will allow core #1 and core #2 to perform real-time processing. Recommendation region 860 may display the contents of the updated collections to a user.

[0088] Estimated processing time 870 may provide a processing time estimate based on the updated schedule that takes into account the updated collections displayed in recommendation region 860. Rerun button 880 may rerun a model, generated code on target environment 130, or code that performs processing estimates for target environment 130 using target characteristics. In an embodiment, information in configuration identifier 850, results region 855 and/or recommendation region 860 may be updated when rerun button 880 is selected.

[0089] FIG. 8C illustrates an exemplary interactive report 890 that can be used to allow a user to interact with computer 110. In an embodiment, a user may interact with report 890 to specify operating characteristics for target environment 130 and/or simulation environment 120. For example, report 890 may allow a user to specify task scheduling mechanisms, information about whether parallel execution is supported on target environment 130, preferred data transfer mechanisms, allowing scheduling overruns, etc. Report 890 may also include a region for displaying information about computational throughput, such as processing times for various code segments (e.g., code segments implementing algorithms), etc.

[0090] In an embodiment, an interactive report may programmatically populate portions of report 890 based on received user inputs. Information included in report 890 may be stored, transmitted to a destination, printed, etc., based on user actions or programmatic instructions executed in system 100.

[0091] FIG. 9 illustrates an exemplary computer architecture that can be used to implement computer 110 of FIG. 1. FIG. 9 is an exemplary diagram of an entity corresponding to computer 110. As illustrated, the entity may include a bus 910, processing logic 920, a main memory 930, a read-only memory (ROM) 940, a storage device 950, an input device 960, an output device 970, and/or a communication interface 980. Bus 910 may include a path that permits communication among the components of the entity.

[0092] Processing logic 920 may include a processor, microprocessor, or other types of processing logic (e.g., FPGA, GPU, DSP, ASIC, etc.) that may interpret and execute instructions. In one implementation, processing logic 920 may include a single core processor or a multi-core processor. In another implementation, processing logic 920 may include a single processing device or a group of processing devices, such as a processing cluster or computing grid. In still another implementation, processing logic 920 may include multiple processors that may be local or remote with respect each other, and may use one or more threads while processing.

[0093] Main memory 930 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processing logic 920. ROM 940 may include a ROM device or another type of static storage device that may store static information and/or instructions for use by processing logic 920. Storage device 950 may include a magnetic, solid state and/or optical recording medium and its corresponding drive, or another type of static storage device that may store static information and/or instructions for use by processing logic 920.

[0094] Input device 960 may include logic that permits an operator to input information to the entity, such as a keyboard, a mouse, a pen, a touchpad, an accelerometer, a microphone, voice recognition, camera, neural interface, biometric mechanisms, etc. Output device 970 may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, a haptic interface, etc. Communication interface 980 may include any transceiver-like logic that enables the entity to communicate with other devices and/or systems. For example, communication interface 980 may include mechanisms for communicating with another device or system via a network.

[0095] The entity depicted in FIG. 9 may perform certain operations in response to processing logic 920 executing software instructions contained in a computer-readable medium, such as main memory 930. A computer-readable medium may be defined as a physical or logical memory device. The software instructions may be read into main memory 930 from another computer-readable storage medium, such as storage device 950, or from another device via communication interface 980. The software instructions contained in main memory 930 may cause processing logic 920 to perform processes described herein when the software instructions are executed on processing logic. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0096] Although FIG. 9 shows exemplary components of the entity, in other implementations, the entity may contain fewer, different, or additional components than depicted in FIG. 9. In still other implementations, one or more components of the entity may perform one or more tasks described as being performed by one or more other components of the entity.

[0097] FIGS. 10A and 10B illustrate exemplary processing for implementing an embodiment. Processing may begin when a model is received (act 1005). For example, an executable graphical model for a physical system, e.g., a physical computing system, may be received at computer 110 via interface logic 230. The model may include a number of blocks and connections that collectively simulate the physical system when executed. These blocks may have underlying source code for implementing the functionality of the blocks. The code may include many functions (e.g., code segments) that operate at different rates when the model is executed. For example, some code segments may execute every 1 ms, other code segments may execute every 2 ms, and still other code segments may execute every 4 ms. The functions may operate with different offsets. For example, a code segment may execute every 1 ms with no offset, other code segments may operate at 2 ms with a 1 ms offset, and still other code segments may execute every 4 ms with a 3 ms offset. In the model, still other code segments may only execute in response to specified events.

[0098] Depending on an implementation of the model, the code segments may execute according to, for example, rate monotonic scheduling, earliest deadline first scheduling, or according to multi-tasking scheduling. For example, it may be desirable to decouple the 0.1 ms code from the 0.2 ms code during model execution. In this situation, multi-tasking scheduling may be used. In contrast, if it is desirable to maintain coupling between code executing a different rates, rate monotonic scheduling may be used.

[0099] Computer 110 may query target environment 130 for target characteristics via interface logic 230 and network 160. Target environment 130 may transmit target characteristics to computer 110 in response to the query. For example, the target characteristics may include information about a number and/or type of real-time logic 140, RT-O/S 135, memory, bus type and/or bandwidth, clock rate, input/output interface type and/or throughput, compiler type, software applications, types of scheduling, whether preemption is supported, etc.

[0100] Computer 110 may receive and may process the received target characteristics to determine what type of scheduling to use when simulating the model and/or when generating code from the model (act 1010). For example, computer 110 may evaluate the target characteristics and may determine that target environment 130 can support multi-tasking scheduling. In this situation, computer 110 may perform simulations of the model using multi-tasking scheduling and may generate code that is adapted for multi-tasking scheduling when executed on target environment 130.

[0101] In another embodiment, computer 110 may cause benchmarking code to be executed on target environment 130, where the benchmarking code is configured to determine performance characteristics of target environment 130 when executing certain code. Computer 110 may receive benchmarking results produced when the benchmarking code is executed on target environment 130. Computer 110 may process the benchmarking results to make determinations with respect to scheduling the execution of blocks in the model when the model is simulated on computer 110 or for code generated by computer 110 for use on target environment 130.

[0102] Code portions for the model may be accessed (act 1015). For example, scheduler 230 may receive code for blocks that will be executed on target environment 130. Scheduler 230 may also access target environment characteristics that are relevant to scheduling code that will execute on target environment 130 (act 1020).

[0103] Referring now to FIG. 10B, scheduler 230 may perform execution scheduling on the code portions of the model (act 1025). Embodiments may allow a user to input an initial execution schedule or may programmatically determine an initial execution schedule with or without user input. For example, scheduler 230 may use target characteristics when determining an execution schedule for components of an executable model. The use of target characteristics allows scheduler 230 to account for actual configurations and/or capabilities of target environment 130 when determining an execution schedule. For example, scheduler 230 may take some or all of the following target characteristics into account: number and/or types of processing logic, amount and type of memory, clock speeds for processing logic and/or memories, input/output interfaces, power requirements, and types of real-time scheduling protocols.

[0104] A report identifying execution scheduling for generated code configured to execute on target environment 130 may be provided to a user (act 1030). For example, an embodiment may provide display 802 or report 890 to a user. Alternatively, the embodiment may provide the report via a hardcopy or a file.

[0105] Computer 110 or the user may determine whether the provided execution schedule is acceptable for a particular segment of generated code that will execute on target environment (act 1035). For example, system 100 may color code portions of display 802 or report 890 to indicate whether certain model components will execute in real-time on target environment 130. Alternatively, a textual identifier may be used to indicate whether an evaluated execution schedule will satisfy real-time constraints when code is executed on target environment 130. Still other embodiments may identify whether schedules are acceptable or unacceptable in still other ways without departing from the spirit of the invention. For example, by superimposing this information on the graphical model or by modifying graphical affordances of the elements in the graphical model, such as the width of blocks and position of connection points.

[0106] When an execution schedule is not acceptable in act 1035, system 100 may receive schedule modifications (act 1045). For example, a user may have initially proposed that blocks execute according to the arrangements of FIGS. 6A and 6B. In response to evaluating an execution schedule for this arrangement, the user may be provided with report 890 that may indicate that the evaluated schedule is unacceptable for real-time operation on target environment 130. The user may enter an updated execution schedule by identifying another execution arrangement for components of a model, e.g., as shown in FIGS. 7A and 7B. System 100 may perform execution scheduling for the updated schedule at act 1025 and may provide updated scheduling results at act 1030.

[0107] When an execution schedule is acceptable at act 1035, code may be generated for the model (act 1040). An embodiment may generate executable source code or machine code that is configured to execute on target environment 130. For example, code generator 290 may generate C++ source code from an executable graphical model built in simulation environment 120 by a user. The C++ code may be configured to execute in real-time on target environment 130 after the code is compiled.

[0108] Computer 110 may transfer the generated code to target environment 130 via network 160, or via another mechanism such as a portable storage device or wireless link (act 1045). The transferred code may be stored on target environment 130 and executed at a determined time or upon occurrence of an event. The code, when executed on target environment 130, may perform real-time operations according to an execution schedule determined on computer 110 using target characteristics.

[0109] In the discussion of FIGS. 10A and 10B, execution schedules were evaluated prior to generating code for execution on target environment 130. Embodiments may be configured to perform execution scheduling assessments after code is generated for target environment 130. For example, target characteristics may be received at computer 110 from target environment 130. Computer 110 may generate code for a specified arrangement of model components, where the arrangement reflects an execution schedule on target environment 130. Computer 110 may determine whether generated code will execute in real-time on target environment 130 using the received target characteristics before transferring the generated code to target environment 130. When the generated code will not execute in real-time on target environment 130, computer 110 may request that a user specify an updated execution schedule or computer 110 may programmatically determine an updated execution schedule. Computer 110 may generate updated code using the updated execution schedule, and then computer 110 may determine whether the updated code will execute in real-time on target environment 130. When the updated code will execute in real-time on target environment 130, computer 110 may transfer the updated code to target environment 130.

[0110] Embodiments can perform execution scheduling for multiple target environments, such as two or more target environments 130 operating in a real-time computing cluster that performs parallel processing. In such an embodiment, computer 110 may evaluate execution schedules that support load balancing among the target environments 130 so as to avoid or reduce idle times of target environments 130 when parallel processing activities are taking place. Computer 110 can be further configured to account for homogeneous or heterogeneous execution schedules among the target environments 130.

[0111] Embodiments of system 100 can also be configured to produce consistent results between simulations performed on computer 110 using simulation environment 120 and for results produced by executing corresponding generated code on target environment 130. For example, computer 110 may compare results produced by simulation environment 120 with results produced on target environment 130. Computer 110 may use an acceptable range of deviation between simulation results and target environment results to determine that the two results are similar enough to be deemed acceptable.

[0112] Embodiments can further be configured to optimize certain characteristics of target environment 130. For example, computer 110 can perform execution scheduling for generated code that is adapted to minimize power consumption on target environment 130 when target environment 130 executes the generated code. Assume that target environment 130 has two real-time processors. Computer 110 may perform execution scheduling that causes the real-time processors to go into a power saving mode (e.g., by running at a reduced clock speed or by powering down) when not actively engaged in real-time computations. Alternatively, if one real-time processor consumes less power than the other real-time processor during computations, computer 110 may cause the lower power real-time processor to operate near 100% capacity while the higher power real-time processor spends time in a power saving mode while still allowing target environment 130 to operate within a real-time constraint.

[0113] Embodiments can be configured to delay a clock for a first group of model components with respect to a clock for a second group of components when delaying one clock with respect to another improves execution scheduling. For example, computer 110 may determine that starting both clocks at the same time relative to each other produces generated code that cannot satisfy a real-time constraint when executed on target environment 130. Computer 110 may then determine an updated schedule that indicates that the real-time constraint can be met when one clock is started at, e.g., t=0 ms, and the other clock is started at t=2 ms. Computer 110 may generate an execution schedule that uses the offset clocks when generating code for target environment 130.

[0114] Embodiments can further be configured to generate code for execution on target environment that can include an execution environment capable of being abstracted via RT-O/S 135. For example, generated code sent from computer 110 to target environment 130 can utilize and/or interface to the execution environment to achieve desired execution scheduling and/or data communications. The execution environment may provide additional application program interfaces (APIs) to facilitate execution scheduling and/or data communication on target environment 130. Examples of APIs that can be used may include, but are not limited to, portable operating system interface (POSIX) threads, multi-core communication API (MCAPI), message passing interface (MPI), OpenMP (by openmp.org), Intel threading building blocks (TBB), boost C++ threads, AUTOSAR, etc. Information about these APIs can be fed back to computer 110 in target characteristics so that a model can leverage the APIs in code generated from the model.

[0115] Exemplary embodiments can be implemented in modeling domains that differ from ones explicitly discussed herein without departing from the spirit of the invention. For example, an executable model may be a model in a formalism that has executable semantics. Embodiments may also be implemented using simulation environments that are modeling environments.

[0116] Exemplary embodiments can be configured using techniques described herein and/or known in the relevant art to perform still other operations in conjunction with schedulability analysis. For example, an embodiment can be configured to optimize task partitioning based on data flow in a model.

[0117] Referring to FIG. 11, a model 1100 may include blocks 1110, 1120 and 1130 representing systems, such as physical computing systems. For example, block 1110 may represent system 1 and may have a sample time of 0.1 ms. Block 1120 may represent system 2 and may have a sample time of 0.2 ms, and block 1130 may represent system 3 and may have a sample time of 0.3 ms. In the example of FIG. 11, block 1110 may output a signal to blocks 1120 and 1130. Model 1100 may also include summation block 1140. Block 1140 may have a sample time of 1.2 ms. Block 1140 may receive output signals from block 1120 and block 1130 and may sum the received signals to produce an output signal that is provided to Output 1, labeled as block 1150.

[0118] In model 1100, the downstream summation block 1140 has a sample time of 1.2 ms which is slower than the sample times for upstream blocks, namely block 1120 (Ts=0.2 ms), block 1130 (Ts=0.3 ms) and block 1110 (Ts=0.1 ms). Since the downstream block 1140 is slow compared to upstream blocks, model 1100 may be optimized by having the computations corresponding to the upstream blocks execute in tasks that run slower, e.g., by using a low power processor that runs at a reduced clock rate. For example, upstream blocks 1110, 1120, and 1130 can run tasks having sample times of 0.1, 0.2, 0.3, 0.4, 0.6 and 1.2 ms without causing block 1140 to wait for data. The embodiment may schedule code segments among the sample times in a manner that does not cause block 1140 to wait for data. The scheduling in model 100 may serve to balance loads for some or all tasks in model 1100. This load balancing may serve to optimize model 110 according to a determined criteria, such as low power, a certain processor cost, reducing processor idle time, etc.

[0119] Embodiments can be configured to perform accurate schedulability analyses based on information known about a model. For example, various intermediate representations may be produced from a graphical model as the model is compiled. The intermediate representations can provide information to scheduler 250 to allow accurate schedule analyses and/or schedule determination. For example, block optimizations, signal optimizations, block or signal relocations, data dependencies, execution rates, expression folding, FOR loop fusion, task remapping, task regrouping, inserting/deleting buffers or blocks (e.g., rate transition buffers), etc., can be performed during the lowering of intermediate representations and this information can be provided to scheduler 250.

[0120] FIG. 12A illustrates a model 1200 that includes an input 1210, gain blocks 1230A, B, and C, discrete time integrator 1240, and output 1250. Model 1200 may be transformed into one or more intermediate representations to generate a compiled version of model 1200. Scheduler 250 may accept information about model 1200 from various stages of intermediate representations and may use the information when performing schedulability analysis for components of model 1200.

[0121] Input 1210 may provide an input signal to components in model 1200. Gain blocks 1230A, B, and C may receive a signal and may amplify the signal by a constant value to produce an amplified output signal. Integrator 1240 may integrate a received signal to produce an integrated output signal. Output 1250 may receive a signal and may output the signal to storage, another model, a subsystem, another block, a function, a method, a display device, etc. In an embodiment, integrator 1240 may include a constant K that can be multiplied with a sample time parameter and/or another parameter. When model 1200 is transformed to an intermediate representation, optimizations can be performed. For example, constants associated with gain blocks 1230A-C can be optimized out of the model using, for example, expression folding techniques.

[0122] FIG. 12B illustrates a model 1205 that does not include gain blocks 1230A-C. In model 1205, the gains associated with blocks 1230A-C have been optimized out of the model and values for the gains have been included in the constant K of integrator 1240A. In an embodiment, model 1205 represent a model when the model is expressed in an intermediate representation.

[0123] Optimization techniques can be used to reduce, remap, or regroup, the number or type of blocks in an intermediate representation as compared to the number/type of blocks in a model from which the intermediate representation is produced.

[0124] FIG. 13 illustrates a model 1300 that includes two input ports 1310 and 1320, two adders 1330 and 1340, and two output ports 1350 and 1360. Input ports 1310 and 1320 may provide signals to adders 1330 and 1340. Adders 1330 and 1340 may receive input signals and may add or subtract the input signals with respect to each other to produce an output signal. Output 1350 and 1360 may receive signals and provide the signal to storage, another model, a subsystem, another block, a function, a method, a display device, etc.

[0125] In model 1300, two-thousand (2000) addition blocks are used to perform calculations. When model 1300 is converted to an intermediate representation, only one-thousand (1000) addition blocks are needed because signal D is actually equal to signal A. Scheduler 250 can accept information from the intermediate representation and can perform scheduling operations that account for 1000 addition blocks instead of 2000 addition blocks.

[0126] FIG. 14 illustrates a state based implementation of a model. State chart 1400 may schedule a conditionally executed subsystem in block 1420 or 1430. Block diagram analysis may be performed and information from the analysis can be provided to scheduler 250. For example, it may be determined based on the analysis that task SS1 and task SS2 need to be scheduled in a base rate task Ts=0.1 ms. An intermediate representation analysis of state chart 1400 may indicate that SS1 runs every 5^th sample hit of 0.1 ms and that SS2 runs every other time that SS1 runs. Schedulability analysis may determine that SS1 and SS2 should be placed in a subrate.

[0127] Exemplary embodiments can be configured and/or implemented in still other ways to benefit from schedulability analysis. For example, schedulability analysis may include optimizing code by inserting an execution of code to improve the schedulability of generated code as compared to schedulability of the generated code without performing the optimization.

[0128] Referring to FIG. 15A, an implementation may include two tasks A and B where each task includes a number of functions, or other types of code. For example, task A can include functions A1, A2, and A3 and task B can include functions B1, B2, and B3. In FIG. 15A, the functions may execute at different times, with function A1 executing before functions A2 and A3 and function B1 executing before functions B2 and B3. The implementation of FIG. 15A may include constraints that are associated with task A and/or task B. For example, a constraint may indicate that function B2 should not execute until after function A2 executes and that function B2 should further execute before function A3 executes. The constraint may specify an execution window 1505 for function B2, where function B2 is said to satisfy the constraint when function B2 executes within the boundaries of execution window 1505. For example, execution window 1505 may allow function B2 to have some amount of jitter, where jitter indicates a deviation in positive time (J′ in FIG. 15A) or negative time (J⁻ in FIG. 15A) with respect to a nominal execution time at which function B2 is expected to execute.

[0129] Task A and task B may share data in the implementation of FIG. 15A. For example, referring to FIG. 15B, the implementation may further include Buffer A 1510 for storing information produced by functions and/or used by functions. For example, task A may execute and function A1 may write to buffer location 1520. After function A1 writes to buffer location 1520, task A3 may execute and may overwrite the information in buffer location 1520 with new information. In the embodiment of FIG. 15B, Buffer 1510 may be shared with task B. For example, function B2 may read a value from buffer location 1520 when function B2 executes.

[0130] In the implementation of FIG. 15B, proper execution of task B may require that function A1 execute before function B2, otherwise function B2 will read an invalid value (e.g., an old value) from buffer location 1520. In addition, proper execution of task B may require that function B2 complete execution before function A3 begins to execute (as shown by execution window 1505 in FIG. 15A) otherwise, function B2 may read a value from buffer location 1520 that was overwritten by function A3 when function A3 was executed.

[0131] For sake of example, assume that task B may overrun due to unexpected waits on account of an execution time for functions included in task A. In this example, it may be determined that task A and task B are coupled because function B2 reads a value associated with the execution of function A1. It may further be determined that making tasks A and B parallel tasks by decoupling them may allow tasks A and B to execute within a determined time interval, e.g., a real-time interval.

[0132] A first technique for de-coupling task A and task B, based on schedulability analysis, may include remapping some or all of task A or task B. For example, a portion of task A can be remapped (e.g., function A1) to eliminate overruns and/or undesirable wait intervals. Referring to FIG. 15C, function A1 may be remapped to task B so that function A1 is in both task A and task B. The remapping causes function A1 to be run twice, once in task A and once in task B and may remove waiting intervals for task A and/or task B. In this example, schedulability may be improved after remapping function A1, as compared to schedulability before function A1 was remapped into task B.

[0133] In a second implementation, additional memory (e.g., a cache) may be added to the embodiment of FIG. 15B, as shown as FIG. 15D, to improve schedulability. Referring to FIG. 15D, buffer location 1530 is added to buffer A and is configured to store information produced by function A3. In the implementation of FIG. 15D, function A1 executes and a value for buffer location 1520 is computed and stored. The value from buffer location 1520 is used by function B2 when it executes. If function A3 executes prior to function B2 executing, a current value in buffer location 1520 will not be overwritten since function A3 writes information to buffer location 1530. Buffer location 1530 may act as a rate transition buffer and may serve to decouple task A from task B during execution.

[0134] Implementations described herein can be configured to achieve determined execution times using schedulability results produced via schedulability analyses. Implementations can perform optimizations with respect to code, architecture usage, etc., based on schedulability results to help achieve desired execution times for generated code. For example, feedback can be employed to further tune code, parameters, etc., based on schedulability results. Assume that schedulability analysis indicates that one or more tasks overrun or are close to overrunning when code is executed. Results from this schedulability analysis can be fed back to a model, code generator, etc., to help optimize code (e.g., to make the code more efficient so that it executes faster) to avoid overruns.

[0135] Further assume that a schedulability analysis indicates that tasks have excess bandwidth when executed. Here a schedulability result can be fed back and used to optimize memory usage even if optimized memory usage may result in some of the tasks executing more slowly without causing overruns or other adverse outcomes. Optimizing memory usage may allow less expensive, smaller, slower, etc., memories to be used for the code than could have been used without optimizing the memory based on the schedulability analysis.

[0136] An implementation may generate a parallel intermediate representation to provide a graph-based representation for use in performing schedulability analysis on a model. The parallel intermediate representation may be an intermediate representation that is used to support schedulability analysis and may differ from other types of intermediate representations that may be used with a model or for generating code from the model. The parallel intermediate representation may be configured to capture parallelism and data rates implied by a source language.

[0137] The parallel intermediate representation may support a default model of execution times assigned to elements in the code. For example, the default model may be used for operations, function-calls, conditions, etc., in the code. In addition, the default model can be used for data (operands) and may include data types and/or memory locations.

[0138] The parallel intermediate representation may also represent code that is associated with different ones of concurrent threads, or tasks, of execution. Here the parallel intermediate representation may provide the ability to identify that a given segment of code or data is associated with a specific one of the concurrent threads of execution. The parallel intermediate representation may further support dependency analysis that can be used to identify opportunities where code may be further parallelized while still maintaining a functional equivalence for the code. The dependency analysis may further be able to represent additional parallel paths of execution.

[0139] The parallel intermediate representation may allow execution timing information to be augmented with target specific information (e.g., target specific timing information). The parallel intermediate representation may use the augmented information in place of the default information when performing schedulability analysis.

[0140] FIGS. 16A and B illustrate exemplary processing that can be used to perform schedulability analysis that takes into account target characteristics. Processing may begin by initiating an analysis engine that can evaluate information contained in an intermediate representation (act 1605). The analysis engine may load a call graph that is described in an intermediate representation (act 1610). The analysis engine may use an intermediate representation that is produced for another purpose, such as for code generation, or may use a intermediate representation that is produced specifically to support schedulability analysis.

[0141] The analysis engine may use the call graph to determine (1) a worst case code path execution time for each block in a model, (2) a best case code path execution time for each block in the model, or (3) a median and/or mean code path execution time for each block in the model (act 1615). The analysis engine may aggregate determined time information to, for example, a thread level (act 1620). For example, function-level timing information may be aggregated to a thread level (e.g., an entry point function of the code might define a unique thread).

[0142] The analysis engine may use the collected timing information to (1) identify imbalances in thread workloads, (2) report imbalances in thread workloads, or (3) determine alternative groupings that provide better workload balancing for parallel threads (act 1625). For example, in an embodiment, the analysis engine may use data dependency information to help balance workloads among parallel threads or to determine an alternative grouping of functions, etc., for particular parallel threads to balance workloads among the parallel threads.

[0143] The analysis engine may receive target environment configuration information (act 1630). For example, target environment 130 may send information to computer 110 in response to a query. Alternatively, computer 110 may retrieve a stored copy of target environment configuration from memory. In still another implementation, a user may manually enter target environment configuration information into computer 110 via input device 125.

[0144] The analysis engine may update an estimation of thread execution time based on the target environment configuration information. The analysis engine may provide the updated estimates of thread execution times to a user or to other components or applications running on computer 110 (act 1635). Scheduling solutions for generated code may be constrained based on scheduling capabilities of the target environment on which the generated code will be executed (act 1640). Results produced by the analysis engine, such as updated estimates of thread execution times, may be used to constrain the scheduling solution for the target environment. Results may be outputted to a user via a display device, stored in a storage medium, transmitted to a destination, printed, etc. (act 1645). The results may include outputs produced by the analysis engine and can include, for example, generated code that implements the constrained scheduling solution, the scheduling solution, etc.

[0145] The exemplary implementation may use a variety of techniques and/or data structures when performing schedulability analysis based on target environment characteristics. For example, a user may be working with a graphical model, such as a Simulink model, that includes blocks and connections (e.g., signal lines). The implementation may create an initial in-memory representation of the model. For example, model 510 (FIG. 5B) may be displayed to a user. Model 510 may include blocks 520A, 530A, 540A, and 550A and connections 560. The in-memory representation of model 510 may be represented in a memory using data structure 1710 (FIG. 17).

[0146] Referring now to FIG. 17, data structure 1710 may include pseudo code representations 1720 for block 520A, representation 1730 for block 530A, representation 1740 for block 540A, and representation 1750 for representation 550A. Data structure 1710 may not include annotations identifying thread allocation information. For example, the code segments of data structure 1710 may be executed serially on a single thread to produce a result. Schedulability analysis can be performed for the code segments based on the assumption that serial execution will be performed. If the schedulability analysis determines that serial execution cannot be performed within a determined interval, such as a time interval for real-time operation, then schedulability analysis may be performed to distribute processing among a number of threads to achieve parallel execution.

[0147] An implementation may create an in-memory intermediate representation that can include, for example, median timing information. Referring now to FIG. 18, an intermediate representation for block 540A of FIG. 17 is illustrated. The intermediate representation may include a workflow comprised of blocks 1805-1830 and intermediate representations 1835, 1840, and 1845.

[0148] Intermediate representations 1835, 1840 and 1845 can include nodes and edges (lines) that connect nodes and may also include arrows to show the flow of information. In FIG. 18, start block 1805 may initiate the workflow. At block 1810, an expression statement may be received. For example, intermediate representation 1835 may represent the expression z=0 of representation 1740 (FIG. 17). From intermediate representation 1835, it can also be determined that a time of 0.1 microseconds (μsec) is required to set z=0.

[0149] At block 1815, a FOR loop may be entered and at block 1825 the FOR loop may be exited. At block 1815, the expression for (i=0; i<10; i++) may be received via intermediate representation 1840. From intermediate representation 1840, it is seen that setting i=0 requires 0.1 μsec, i<10 requires 0.2 μsec, and i++ requires 0.4 μsec. Within the FOR loop, the expression z=a+1.3*z may be evaluated.

[0150] At block 1820, intermediate representation 1845 may be received. Within intermediate representation 1845, 1.3*z may take 0.6 μsec, adding a to 1.3*z may take 0.3 μsec, and z=a+1.3*z may take 0.1 μsec.

[0151] A total processing time for block 540A is represented by T1+T2+10 (T3+T4+T5+T6+T7), which is 16.2 μsec. In some situations, 16.2 Ξsec may be an unacceptably long processing time for block 540A.

[0152] Exemplary implementations may use dependency analysis to help with schedulability analysis to identify a satisfactory execution schedule for block 540A. Now referring to FIG. 19, dependency table 1900 may include information about dependencies between blocks in a model. For example, from table 1900 it is determined that block 540A depends on variable a and provides variable z. Table 1900 also indicates that block 540A has a median processing time of 16.2 μsec. In an embodiment, table 1900 can be derived from pseudo code, such as the pseudo code illustrated in FIG. 17. Information in table 1900 can be sorted if desired, for example, code block timing may be sorted by media processing time.

[0153] Schedulability analysis may employ a heuristic, such as sorting blocks of code from a highest to a lowest median time. The analysis may allocate the sorted blocks of code to a thread/task until a thread-total-time is greater than thread-total-times for other threads. This approach may be repeated and may produce a concurrent thread allocation that is optimized with respect to concurrent thread allocations that are performed using another technique. Other implementations may use other sorting techniques (e.g., dynamic sorting techniques that can sort on substantially any attribute) and/or allocation techniques (e.g., cycling through available threads and assigning code blocks to the available threads from a list ordered based on descending times).

[0154] FIG. 20 illustrates an exemplary GUI 2000 that can display thread allocations that are made using processing times for code blocks and/or data dependency information for the code blocks. In FIG. 20, representation 2010 may display information for a first thread (Thread1). For example, block 540A may be allocated to Thread1. Representation 2020 may indicate that Thread2 includes code for block 520A and 530A, and representation 2040 may indicate that code for block 550A is also allocated to Thread2. Implementations may identify the need for synchronization logic, such as a synchronization point, to synchronize the execution of threads. The use of synchronization logic ensures that proper data dependence is maintained and thus equivalent numerical results are achieved between the concurrent and sequential execution of the code. In FIG. 20, representation 2030 may indicate a synchronization point and may provide text explaining what the synchronization point is configured to accomplish.

[0155] Implementations may use target characteristics to perform execution scheduling for generated code adapted to execute in a target environment.

[0156] The foregoing description of exemplary embodiments of the invention provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. For example, while a series of acts has been described with regard to FIGS. 10A and B, the order of the acts may be modified in other implementations consistent with the principles of the invention. Further, non-dependent acts may be performed in parallel.

[0157] In addition, implementations consistent with principles of the invention can be implemented using devices and configurations other than those illustrated in the figures and described in the specification without departing from the spirit of the invention. Devices and/or components may be added and/or removed from the implementations of FIG. 1 or 2 depending on specific deployments and/or applications. Further, disclosed implementations may not be limited to any specific combination of hardware.

[0158] Further, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include hardware, such as hardwired logic, an application-specific integrated circuit, a field programmable gate array, a microprocessor, software, or a combination of hardware and software.

[0159] No element, act, or instruction used in the description of the invention should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on,” as used herein is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

[0160] Headings and sub-headings used herein are to aid the reader by dividing the specification into subsections. These headings and sub-headings are not to be construed as limiting the scope of the invention or as defining the invention.

[0161] The scope of the invention is defined by the claims and their equivalents.