Showing posts with label Floating Point to Fixed Point Conversion. Show all posts
Showing posts with label Floating Point to Fixed Point Conversion. Show all posts

Friday, September 24, 2010

Model Based Design – VIP Appln -03


Model-Based Design to Develop and Deploy a
Video Processing Application

03 Generating Automatic Code using Real Time Workshop

During simulation, the flexibility and generality provided by fixed-point operators as they check for overflows and perform scaling and saturations can cause a fixed-point model to run slower than a floating-point model. To speed up the simulation, we can run the fixed-point model in Accelerator mode. The Simulink Accelerator can substantially improve performance for larger Simulink models by generating C code for the model, compiling the code, and generating a single executable for the model that is customized to a model's particular configuration. In Accelerator mode, the simulation for the fixed-point model runs at the speed of compiled C code.

Code is generated using Real-Time Workshop in the folder named: modelfilename_mode_rtw (ex. MBD_LineDetection_CodeGen_accel_rtw), like below-

Figure 6: Generated Code with RTW

Model Based Design – VIP Appln -01


Model-Based Design to Develop and Deploy a
Video Processing Application

Purpose -

Model-Based Design with Simulink®, Video and Image Processing Blockset, Real-Time Workshop® and TIC6000 Blockset can be used to design a embedded system, to implement the design on a Texas Instruments DSP, and to verify its on-target performance in real time.


Why this approach?

The core element of Model-Based Design is an accurate system model— an executable specification that includes all software and hardware implementation requirements, including fixed-point and timing behavior. We use the model to automatically generate code and test benches for final system verification and deployment. This approach makes it easy to express a design concept, simulate the model to verify the algorithms, automatically generate the code to deploy it on a hardware target, and verify exactly the same operation on silicon.

Steps -

  1. Building the System Model using Mathworks Simulink
  2. Converting the Design from Floating Point to Fixed Point
  3. Automatic code generation using RTW/RTW Embedded Coder
  4. Implementing and Verifying the Application on TI Hardware


01 Building the System Model – Algorithm

Using Simulink, the Signal Processing Blockset (SP Blockset), and the Video and Image Processing Blockset (VIP Blockset), first develop a floating-point model of canny edge detection system. This model detects the edges of input video using a complex 'canny' edge detection algorithm.
Input a video stream to the simulation environment using the "From Multimedia File block" from the VIP Blockset. During simulation, the video data is processed in the Edge Detection subsystem, which outputs the detection algorithm results to the "To Video Display block" for video visualization.
The main subsystem of our Simulink model is canny edge detection. The sequence of steps in the edge detection algorithm maps naturally to the sequence of subsystems in the model.
We begin with a preprocessing step in which we define a relevant field of view and filter the output of this operation to reduce image noise. We then determine the edges of the image using the Edge Detection block in the Video and Image Processing Blockset. With this block we can use the Sobel, Prewitt, Roberts, or Canny methods to output a binary image, a matrix of Boolean values corresponding to edges.

Figure 1: Top Model in Floating-Point

Figure 2: Subsystem – Canny Edge Detection with Preprocessing
        

Figure 3: Results of Floating-Point

Sunday, September 12, 2010

Model Based Design – Things to Know


Model-Based Design – Things to Know

Matlab Simulink and Stateflow based model design

The availability of sophisticated tools and new development techniques has provided great support to control engineers in overcoming these challenges. For instance, the model-based control design software, such as Matlab's Simulink and Stateflow, helps control engineers to recognize problems early on and reduce risk. With built-in mathematical functions and routines these tools are optimized for designing and analyzing control strategies through off-line simulation. Moreover these tools can be integrated with real-time hardware which means integrating traditional off-line simulation with real-world testing.

Benefits:

  • Elimination of errors early in the design
  • Robust control system
  • Fewer iterations in the development cycle
  • Reduced development time and cost


Design validation using Simulink simulation

Simulink facilitates designing of the control algorithm and also helps in executing off-line simulation on the desktop. But it doesn't mean that with software simulations all the distinctive behaviors of an actual dynamic environment can be accounted for.


Code Generation using RealTime Workshop or TargetLink

Tools such as Matlab's Real-Time Workshop (RTW) or dSPACE's Targetlink helps to create the prototype as well as the production code directly from the control design models. The greatest advantage of this process is the significant time and cost savings thanks to the inherent reproducibility and testability of the generated code.


Model-In-Loop validation (MIL)

The Model-in-the-loop simulation captures the specified behavior of the model that is to be implemented in C code later on. These simulated results are validated with the requirements. Also it acts as the verification reference for the next stages of development cycle. Since the model acts as the design document, it reduces the defects slippage due to translation of requirements to design.


Software-In-Loop validation (SIL)

The Software-in-the-loop simulation captures the behavior of the generated C code in simulator environment of the target controller. The simulated results when validated with the simulated Model-in-the-Loop simulation results both the results should be identical. If found otherwise the results can be used to evaluate the cause of deviation.


Automated Testing using Reactis, Embedded Tester, WinAMS, HEW Testing Tools

In the case of Simulink/Stateflow models the Software-in-the-loop simulation is improved by creating test cases using Reactis/Embedded Tester. These test cases not only simulate Simulink/Stateflow but also generate C code. This C code is then tested in WINAMS or HEW environment.


Hardware-In-Loop validation (HIL)

In hardware-in-the-loop (HIL) testing, the designer can verify the production system controller by simulating the real-time behavior and characteristics of the final system without the physical hardware or operational environment. While the system is simulated in real-time on a test computer the control code can be run on the target controller hardware. Though it is possible to connect the target hardware with the actual engine, testing against a simulated engine offers several advantages. When compared to a physical plant, a desktop simulator, often called a hardware-in-the-loop (HIL) tester, is far more cost-efficient, and easier to reproduce. The simulated engine also can simulate a variety of operating conditions or even fault conditions, such as engine stall, that would be difficult, costly, and/or dangerous with the actual plant. If measured data from HIL simulation deviates from Model-in-the-Loop simulation, the most likely cause is a bug in the target compiler or a problem with the processor.


Reverse Engineering of legacy code to Simulink models

The existing legacy C code is converted to equivalent Simulink/Stateflow models. This acts as specification for the legacy code, and maintenance of these specification will be easier, which may lead to auto code generation possible for future updates.

 

References:

  1. http://blogs.mathworks.com/seth/2009/05/13/what-does-model-based-design-mean-to-you/
  2. http://www.mathworks.com/model-based-design/#
  3. http://www.mathworks.com/help/toolbox/simulink/gs/brc32o8-2.html
  4. http://www.embedded360.com/model_based_development/model_based_development.htm
  5. http://electronicdesign.com/article/eda/model-based-design12086.aspx
In the next blog, we will see in detail with an example of video analytics

Saturday, September 11, 2010

Model Based Design (MBD)


Model Based Design of Embedded Systems

Target platforms needed to be the first choice when developing systems using assembler. Moving on to C, designers had more flexibility. But they were quickly locked into a specific target as the run-time libraries prevented migration to different platforms. Platform choice was less of an issue when there were fewer targets available. Yet these days, the options are mindboggling. It's no longer just a choice between processor A and processor B. Digital signal processors (DSPs), digital signal controllers (DSCs), multiple core processors, and even FPGAs are viable targets for embedded systems. With embedded solutions, it is target. Optimizing system cost, performance, and flexibility means choosing the proper target. But these days, software is such an important part of the solution, the choice of target and software tools is tied together? means, unless you use abstraction to disconnect these choices. This progression leads to model-based design.
Model-Based Design (MBD) is a mathematical and visual method of addressing problems associated with designing complex control systems. Model-Based Design is a process that enables faster, more cost-effective development of dynamic systems, including control systems, signal processing, and communications systems. In Model-Based Design, a system model is at the center of the development process, from requirements development, through design, implementation, and testing. The model is an executable specification that is continually refined throughout the development process. After model development, simulation shows whether the model works correctly.
When software and hardware implementation requirements are included, such as fixed-point and timing behavior, you can automatically generate code for embedded deployment and create test benches for system verification, saving time and avoiding the introduction of manually coded errors. Automatic program synthesis allows the generation of C code or a representation in a hardware description language (HDL). The HDL emulation can then be co-simulated in the system context to study behavior of an implementation at a cycle accurate level. This reduces expensive hardware iteration, facilitates analysis of system characteristics with detailed component implementation models, and mitigates the need for extensive test bench design.
MBD provides an efficient approach for establishing a common framework for communication throughout the design process while supporting the development cycle ("V" diagram). In Model-based design, development is manifested in these four steps:
  • Modeling a plant,
  • Analyzing and synthesizing a controller for the plant,
  • Simulating the plant and controller, and
  • Integrating all these phases by deploying the controller.
The model-based design paradigm is significantly different from traditional design methodology. Rather than using complex structures and extensive software code, designers can use MBD to define models with advanced functional characteristics using continuous-time and discrete-time building blocks. These built models used with simulation tools can lead to rapid prototyping, software testing, and verification. Not only is the testing and verification process enhanced, but also, in some cases, hardware-in-the-loop simulation can be used with the new design paradigm to perform testing of dynamic effects on the system more quickly and much more efficiently than with traditional design methodology.

Figure 1: Development Cycle ("V" diagram)

 

The important steps in MBD approach are:


  1. System identification (modeling the plant) an iterative process: -     By acquiring and processing raw data from a real-world system and choosing a mathematical algorithm with which to identify a mathematical model, the plant model is identified. Various kinds of analysis and simulations can be performed using the identified model before it is used to design a model-based controller.

  2. Controller analysis and synthesis: -    The mathematical model conceived in step 1 is used to identify dynamic characteristics of the plant model. A controller can be then be synthesized based on these characteristics.

  3. Offline simulation: -    The time response of the dynamic system to complex, time-varying inputs is investigated. This is done by simulating a simple LTI or a non-linear model of the plant with the controller. Simulation allows specification, requirements, and modeling errors to be found immediately, rather than later in the design effort.

  4. Deployment: -    Ideally this is done via automatic code generation from the controller developed in step 3. It is unlikely that the controller will work on the actual system as well as it did in simulation, so an iterative debugging process is done by analyzing results on the actual target and updating the controller model. Model based design tools like VisSim allow all these iterative steps to be performed in a unified visual environment.
Figure 2: Design Approach

Model-Based Design solution include:

  • Algorithmic design & modeling using Mathworks products
  • "Translation" of Matlab/Fortran/C into Simulink Models
  • Creating generic custom toolboxes
  • Integration of legacy C-Code into Simulink blocks
  • Automatic code generation using RTW/RTW Embedded Coder
  • Verification & Validation

Model-Based Design allows us to improve efficiency by:

  • Using a common design environment across project teams
  • Linking designs directly to requirements
  • Integrating testing with design to continuously identify and correct errors
  • Refining algorithms through multidomain simulation
  • Automatically generating embedded software code
  • Developing and reusing test suites
  • Automatically generating documentation
  • Reusing designs to deploy systems across multiple processors and hardware targets

Challenges:


With regard to the designing of embedded systems there are several challenges that the control engineers face and they are:

  • Delivering products to market faster at lower cost
  • Delivering implementations for increasingly complex systems
  • Producing superior quality products
  • Fewer system prototypes
  • Flexible enough to adjust to last minute changes