1 Executive Summary
This discussion addresses the basic question posed by someone evaluating Foresight for their company development process: “What does use of Foresight buy me as opposed to creating a custom C++ model?”. For years people have been creating customized simulators for product development. For a company not in the business of simulator tool creation, such efforts are often under funded and tightly scheduled. The efforts required to create the simulator framework and then product specific model C++ code usually result in a functionality limited model that is a one shot tool for the intended product development.
In a nutshell, the basic advantage of using a commercial off the shelf simulator is productivity in many flavors:
· It allows non-simulator tool companies to have their designers concentrate on developing their product instead of producing a simulator, which can be a major effort in its own right.
· Custom simulators are often built from the ground up, whereas use of commercial simulator tools means access to a simulator infrastructure of library blocks, debugging at the application level, and visualization tools.
· Instead of spending time creating a simulation environment, reusing the simulator product’s infrastructure allows the designer to concentrate on designing their company’s product, exploring alternative designs, and testing the design.
· The graphical modeling environment of Foresight allows users to create hierarchical self-documenting models that are easier to understand, maintain, and discuss with others.
The net result for users are more robust designs in less time.
2 What is Foresight?
The Foresight modeling environment is a series of tools used to create high-level mathematical models of systems. Foresight can capture both the functional algorithmic behavior and implementation architectural interaction of a system. It is a general simulation environment built upon a discrete event simulation kernel. Graphically based, Foresight allows the user to draw a diagram of interconnected concurrent process blocks that can pass data and control signals between the blocks. Other simulation tools excel in algorithm development (number crunching), but do not incorporate the block execution times when they are implemented in hardware, such as software executing on a general purpose CPU, FPGA, or custom ASIC. Foresight adds value to the simulation equation by a resource-modeling feature that reflects the fact that in the real world, processing takes non-zero time. In keeping track of this real world attribute, Foresight allows the user to create performance models that gives the user insight into system behavior and performance attributes such as throughput, bandwidth, power utilization, and helps identify architecture bottlenecks. This can be done early on in a project, which is the best time to make informed architecture tradeoffs and decisions. It is far less costly to address performance issues before a product is built than it is to deal with such issues after the engineering efforts create an implementation.
2.1 Key Distinction: Resource Modeling
The resource model is generic and open. This allows Foresight to be applied to many application domains where the nature of the application being modeled changes with what the resources represent. The built in resource model supports three kinds of resources:
· Basic passive resources that represent something needed to do a job, but does not accomplish the work. The essential attribute of the entity is capacity or amount of the resource. Examples would be memory in electronic systems.
· Basic active resources that represent an entity that performs the work to accomplish a job. The essential attribute of the entity is the rate at which it does the work. An example would be a CPU in electronic systems.
· User Defined Resources (UDR) that are the open mechanism in Foresight that allow users to extend and customize the resource model beyond the two built-in elements. An example would be a specific RTOS scheduling paradigm for a CPU in electronic systems.
3 Suitable Foresight Applications
When creating computer models of anything, one is abstracting away some degree of details to make the mathematical representation of the system. Foresight’s primary forte is high-level modeling, which means it is best utilized early on in a project to assist in making the major architectural decisions of an application, such as how to map or allocate algorithmic behavior onto hardware implementations. For example, “Can an algorithm be performed in software on a general CPU or must it be in hardware (ASIC) for the overall system to meet performance requirements?”
By allowing the user to rapidly move the assignment of algorithmic behavior to different architectural elements within a system, the user is able to see the effect on overall system performance and explore the design space to optimize a system design and implementation for what is important, such as power, cost, and meeting hard real time requirements.
Often first versions of such models are “token” passing models where “real” data to be processed by the application is not passed, but only the important attributes, such as size or how many elements are over threshold, are passed throughout the model. These attributes are often enough to determine bounds on execution times of system architecture elements and therefore overall system performance. For example, in signal processing applications the size of an FFT or FIR filter is what determines the execution time and memory usage, not the data values themselves.
Not all performance attributes are known a priori when the high level model is first created. As a project unfolds it is possible to evolve a Foresight model by adding more details to decrease the level of abstraction. If a performance issue is not discovered until after system implementation is complete, it is often very costly to correct, involves system design changes, and again waiting until implementation is complete to tell whether the revised system will work. Use of Foresight yields insight into system performance issues prior to having to build it. As the project progresses, estimates for performance numbers of the subsystems can be applied to an evolving Foresight model to re-confirm the system will still perform as expected when completely built.
3.1 Sensitivity Analysis
Sensitivity analysis is the process of changing attribute estimates to see how important a particular factor is to the overall system behavior. The estimates could be for execution time, power usage, memory usage, or any of the critical resource attributes that are important to your design. The analysis allows decisions to be made on where to best spend development resources for the most impact on the product under design. For example, is it worth spending the time converting a software module from C to assembly when the expected decrease in execution time will not affect system performance?
3.2 Co-Simulation
As a further aid to model refinement, Foresight provides connection to other simulators, such as HDL tools to provide a co-simulation capability. This means the two tools are simultaneously executing: Foresight executes the overall system model, while the co-simulation tool executes the detailed HDL code implementation of selected blocks. This lets each of the HDL designed blocks to be tested within the context of the overall system, not just in a stand-alone mode.
4 Why Use Commercial Modeling Tools?
4.1 Focus on You Company’s Product
The bottom line reason to purchase simulation tools rather than create custom tools is the productivity gain of not having to build a complex and extensive simulation infrastructure that helps the modeling effort. Examples of simulation features that promote productivity of users are debugging features such as breakpoints, single stepping, and visibility into the state of signals. Instead of having to build this superstructure, using a formal simulator tool allows the engineer to concentrate on the design and implementation of the company’s product.
4.2 Use of Library Blocks
Foresight has about 110 pre-built and validated blocks that may be used to create a model. As a set, these blocks have advanced modeling features that make them easier to use. These features are often not available in custom simulations:
· Overloading of flow data types relieves the user of strong typing where possible
· Support for multiple flow type port connections
4.3 Multiple Models of Computation
Within Foresight, Data Flow Diagrams (DFD), procedural blocks, State Transition Diagrams (STD), and hardware design language (HDL) blocks all represent different activation and structural paradigms for representing the product under design within a model.
· DFDs are good for representing interconnections between networks of concurrent process blocks where the connections represent data and control passing between the blocks.
· The essence of procedural blocks is that they are activated when all their inputs are available, do their algorithms, produce their outputs and then go to sleep.
· Contrast the needing all input behavior with STD blocks which maintain state information, need only one input available to activate and move to a new state while possibly producing outputs before going back to sleep.
· HDL blocks tie into co-simulation tools that mimic the behavior of hardware to the bit level. These are good for supporting system modeling where the sensitivity of the system performance is identified to be in blocks that will be HDL based.
System level models may find it advantageous to select from several of these models of computation to represent different portions of a model. For example, DFDs are good for sequential and parallel computation, while STDs are suitable for representing protocols and mode control.
Figure 1 Sample Data Flow Diagram of Shared Memory Model
5 Graphical Modeling
The top down high-level modeling usage methodology within Foresight is to draw hierarchical DFDs and STDs consisting of connected process blocks until primitive blocks that perform abstractions of algorithms are identified. As illustration of the power of this methodology, the Figure 1 represents a shared memory architecture with multiple performance statistics being gathered. Up to 3 CPUs can simultaneously access a common memory while each CPU runs a different series of algorithms (labeled as functions in the diagram). Each of the user’s blocks can be opened hierarchically to see the next level of detail in the model. The tasking assignment for each CPU is depicted in the upper left corner, the shared memory architecture is in the lower left with flows showing the connections of data, and the gathered statistics are being plotted via the strip chart on the right half of the diagram. Would C++ source code be as easily comprehensible at the same abstraction level? Graphical modeling increases productivity and communication among engineers.
5.1 Easier to Understand and Develop Models
An old saying that “a picture is worth a thousand words” applies to Foresight as illustrated in the opening paragraph of this section. The diagrams of Foresight can quickly convey the overall structure of the functionality of a processing string of blocks, as above, or that of the inner workings of a primitive block, as shown in Figure 2. This is an STD that happens to control the interaction of a CPU and associated shared memory. Another diagram in this model provides the design plan of characterizing functions executed by the CPU into gross segments of CPU with local memory activity followed by CPU with shared memory accesses. With this information, one can then quickly look at the states (rounded rectangles) and the transitions (directed lines) between the states, and see the overall protocol consists of:
· Starts with the CPU “Waiting” for a job
· It then starts a loop to process the segments of a function or CPU job
· Each segment begins with waiting for CPU instructions accessing local memory (WaitForCPU)
· Dispatching of CPU instructions to be executed along with shared memory access (DispatchMem&CPU)
· Then states to handle the possibilities of either the CPU finishing its work first or that of the shared memory doing so (WaitOnMemory and WaitOnCPU, respectively)
· The bottom of the loop either continues the loop or the STD goes back to waiting for a new CPU job.
Could this protocol be so easily represented as C++ code?
Figure 2 CPU-Shared Memory Access Protocol State Machine
5.2 Rapid Changes
When making major changes to C++ source code, one must declare variables, add them to call argument lists, and perform operations in a sequence for the code to work. In the graphical paradigms supported in Foresight, changes are made by reconnecting flows to the block ports and the simulation kernel handles the transport of data to process blocks who then execute per paradigm rules controlled by the simulation kernel. The graphical connections capture any data dependency or sequencing needed between the primitive operations represented by the blocks.
5.3 Self Documenting
Graphical models tend to be self-documenting in that the overall structure and interaction of process blocks is already captured in the structure of the diagram. The hierarchy of the model or decomposition of the application is readily apparent from the each diagram representing the decomposition of the blocks. The flow of data between the blocks shows the level of interaction in an intuitive manner. When one reaches a primitive block, it is either a pre-built, tested, and documented library element supplied with Foresight or a user defined block. At that level the functional algorithm of each block should be relatively small and straight foreword when good design processes are followed. As such, primitive blocks are easily understood in the MiniSpec language that implements it, or if needed, in legacy C source code dynamically linked to the model.
6 Overall Reason to Use Foresight
The points presented here are only some of the reasons to select the Foresight tool suite to perform high level modeling of applications. The bottom line value proposition for using Foresight instead of creating a custom C++ based simulation tool is several fold:
· Your people concentrate on activities directly related to designing your company’s product, not on creating a simulation engine.
· Your people are able to leverage the simulation work of others and concentrate on making your product more robust in a smaller time frame.
· The models created represent designs that are more easily discussed and maintained due to their graphical self-documenting nature.
· More easily changed models encourage the use of sensitivity analysis and design space tradeoff studies to explore design alternatives rapidly.
· Multiple computational models are supported via the foundational Data Flow Diagram and State Transition Diagram paradigms.
Overall, more time is spent directly on your product design and not on infrastructure.