Thread Subject: How much of the App in Simulink/RTW

Hi,

We're working on a new project and are planning on using Simulink/RTW for video processing algorithm development.

What's not clear to me is what we do about the supporting infrastructure. Do we try and develop the whole application in Simulink or do we import the generated code in to a hand coded application?

The application involves multiple TI processors (C6455 and OMAPL-137) and an FPGA.

We've started algorithm development and I've generated code and run it on a TI DSK6455 by creating a Code Composer Studio project and writing a simple app to call the model step function.

Obviously in reality the app will be much more complicated. It will need to handle incoming video data and configuration data that will be arriving via Serial Rapid I/O, it will be running multiple algorithms, etc.

We don't have a license for IDE Link or Target Support Package. Perhaps we should?

Any thoughts or pointers to further reading greatly appreciated!

Thanks,
Matt

"Matt " <remove.this.matt_d_br@hotmail.com> wrote in message
news:hdgksm$3rh$1@fred.mathworks.com...
> Hi,
>
> We're working on a new project and are planning on using Simulink/RTW for
> video processing algorithm development.
>
> What's not clear to me is what we do about the supporting infrastructure.
> Do we try and develop the whole application in Simulink or do we import
> the generated code in to a hand coded application?
>
> The application involves multiple TI processors (C6455 and OMAPL-137) and
> an FPGA.
>
> We've started algorithm development and I've generated code and run it on
> a TI DSK6455 by creating a Code Composer Studio project and writing a
> simple app to call the model step function.
>
> Obviously in reality the app will be much more complicated. It will need
> to handle incoming video data and configuration data that will be arriving
> via Serial Rapid I/O, it will be running multiple algorithms, etc.
>
> We don't have a license for IDE Link or Target Support Package. Perhaps we
> should?
>
> Any thoughts or pointers to further reading greatly appreciated!
>
> Thanks,
> Matt
>

Hi Matt,

The best thing to do is to contact your account manager, who can put you in
touch with an application engineer specialised in the area of production
code generation, which is an advanced topic:
http://www.mathworks.com/company/aboutus/contact_us/contact_sales.html

Based on my limited knowledge, here what I can say:
- Real-Time Workshop allows you to generate ANSI C code from Simulink. The
generated C code is suitable for rapid prototyping and HIL simulations, but
not for embedding on production hardware, as it's not optimized in any way.
You also have very little control over how the code is generated.
- Real-Time Workshop Embedded Coder allows you to customize and optimize (in
terms of size and efficiency) the code generated by Real-Time Workshop
(which is a required product for Embedded Coder) for production use.
- The code generated by Real-Time Workshop and Real-Time Workshop Embedded
Coder is generally speaking, only for the alogirthmic part of the
application. Typically, the low-level driver routines and firmware are
hand-written and integrated with the automatically generated code. However,
there are a few specific targets for which hardware-specific blocks (e.g.
I/O blocks) are provided. This is with the Target Support Package. You can
see which devices are supported at
http://www.mathworks.com/products/target-package/supportedio.html.
- To facilitate the integration of hand-written and automatically generated
code, and interfacing to the hardware, the Embedded IDE Link integrates the
code that is generated directly into the IDE. You can see which IDEs are
supported at http://www.mathworks.com/products/ide-link/supportedio.html
(CCS is supported). The Embedded IDE Link is a required product for Target
Support package.

For FPGAs, I assume you are using VHDL or Verilog, in which case you might
want to look at Simulink HDL Coder and the EDA Simulator Link.

I hope this helps clarify things a bit.

Arnaud

"Matt " <remove.this.matt_d_br@hotmail.com> wrote in message <hdgksm$3rh$1@fred.mathworks.com>...
> Hi,
>
> We're working on a new project and are planning on using Simulink/RTW for video processing algorithm development.
>
> What's not clear to me is what we do about the supporting infrastructure. Do we try and develop the whole application in Simulink or do we import the generated code in to a hand coded application?
>
> The application involves multiple TI processors (C6455 and OMAPL-137) and an FPGA.
>
> We've started algorithm development and I've generated code and run it on a TI DSK6455 by creating a Code Composer Studio project and writing a simple app to call the model step function.
>
> Obviously in reality the app will be much more complicated. It will need to handle incoming video data and configuration data that will be arriving via Serial Rapid I/O, it will be running multiple algorithms, etc.
>
> We don't have a license for IDE Link or Target Support Package. Perhaps we should?
>
> Any thoughts or pointers to further reading greatly appreciated!
>
> Thanks,
> Matt

Matt,

I'd say the choice depends on:
1 - budget;
2 - resources available (man power AND Simulink/RTW/etc. skills and experience);
3 - how much and how well your real world system/task/problem can be represented in Simulink.

In the past I've found (3) critical for custom apps - e.g.: explicit handling of pointers is completely alien to Simulink, while it may be very important for memory management in your app. Conversely, algorithms development is often made easier by Simulink block-diagram structure.

If your app cannot be fully represented/described via Simulink block-diagrams, but you are happy with developing algorithms and autocoding them, you can just use RTW, defining algorithms' I/O in terms of Simulink Global/Exported signals and leaving all optimizations to the compiler.

Otherwise, if Simulink is suitable for representing your entire app, subject to (1) you may try using Embedded Coder, which gives you more influence on the code generation process.

For the rest:
- High (1) Low(2) => besides tools, some consultancy time may help to speed-up development & to facilitate acquiring skills;
- Low (1) High (2) => unlikely you're going to get beyond Simulink/RTW for individual algorithms; autogenerated code modules will have to be integrated - at build time - with hand-written modules.

HTH
Riccardo

Of course, Video and Image Processing blockest might come in handy as well.

Witek



Arnaud Miege <arnaud.miege@nospam.mathworks.co.uk> wrote:
>
> "Matt " <remove.this.matt_d_br@hotmail.com> wrote in message
> news:hdgksm$3rh$1@fred.mathworks.com...
> > Hi,
> >
> > We're working on a new project and are planning on using Simulink/RTW for
> > video processing algorithm development.
> >
> > What's not clear to me is what we do about the supporting infrastructure.
> > Do we try and develop the whole application in Simulink or do we import
> > the generated code in to a hand coded application?
> >
> > The application involves multiple TI processors (C6455 and OMAPL-137) and
> > an FPGA.
> >
> > We've started algorithm development and I've generated code and run it on
> > a TI DSK6455 by creating a Code Composer Studio project and writing a
> > simple app to call the model step function.
> >
> > Obviously in reality the app will be much more complicated. It will need
> > to handle incoming video data and configuration data that will be arriving
> > via Serial Rapid I/O, it will be running multiple algorithms, etc.
> >
> > We don't have a license for IDE Link or Target Support Package. Perhaps we
> > should?
> >
> > Any thoughts or pointers to further reading greatly appreciated!
> >
> > Thanks,
> > Matt
> >
>
> Hi Matt,
>
> The best thing to do is to contact your account manager, who can put you in
> touch with an application engineer specialised in the area of production
> code generation, which is an advanced topic:
> http://www.mathworks.com/company/aboutus/contact_us/contact_sales.html
>
> Based on my limited knowledge, here what I can say:
> - Real-Time Workshop allows you to generate ANSI C code from Simulink. The
> generated C code is suitable for rapid prototyping and HIL simulations, but
> not for embedding on production hardware, as it's not optimized in any way.
> You also have very little control over how the code is generated.
> - Real-Time Workshop Embedded Coder allows you to customize and optimize (in
> terms of size and efficiency) the code generated by Real-Time Workshop
> (which is a required product for Embedded Coder) for production use.
> - The code generated by Real-Time Workshop and Real-Time Workshop Embedded
> Coder is generally speaking, only for the alogirthmic part of the
> application. Typically, the low-level driver routines and firmware are
> hand-written and integrated with the automatically generated code. However,
> there are a few specific targets for which hardware-specific blocks (e.g.
> I/O blocks) are provided. This is with the Target Support Package. You can
> see which devices are supported at
> http://www.mathworks.com/products/target-package/supportedio.html.
> - To facilitate the integration of hand-written and automatically generated
> code, and interfacing to the hardware, the Embedded IDE Link integrates the
> code that is generated directly into the IDE. You can see which IDEs are
> supported at http://www.mathworks.com/products/ide-link/supportedio.html
> (CCS is supported). The Embedded IDE Link is a required product for Target
> Support package.
>
> For FPGAs, I assume you are using VHDL or Verilog, in which case you might
> want to look at Simulink HDL Coder and the EDA Simulator Link.
>
> I hope this helps clarify things a bit.
>
> Arnaud
>
>
>
>

R2009b version of the Target Support Package product supports code
generation for both of the processors that you are targeting (only the DSP
part of the OMAP-L137 is supported for code gen). There are device driver
support for both platforms such as SRIO on C6455 and Ethernet (TCP/IP and
UDP) on both platforms. This might make your data I/O easier.

In general, I would recommend prototyping your algorithm in Simulink.
Incrementally testing components by generating code from the Simulink model
and verifying them on the board. This way, you can slowly build the entire
application while continuosly verifying the algorithm on the final platform
it is intended to un. Simulink makes it much easier to develop algorithms
because of its graphical nature. After building the entire application in
Simulink and verifying that it works as expected, I would move onto the
optimization step where you may want to replace certain parts of the
auto-generated code or go into DMA based block processing etc.

"Riccardo" <nothx@nospam.org> wrote in message
news:hdh7pp$iqi$1@fred.mathworks.com...
> "Matt " <remove.this.matt_d_br@hotmail.com> wrote in message
> <hdgksm$3rh$1@fred.mathworks.com>...
>> Hi,
>>
>> We're working on a new project and are planning on using Simulink/RTW for
>> video processing algorithm development.
>>
>> What's not clear to me is what we do about the supporting infrastructure.
>> Do we try and develop the whole application in Simulink or do we import
>> the generated code in to a hand coded application?
>>
>> The application involves multiple TI processors (C6455 and OMAPL-137) and
>> an FPGA.
>>
>> We've started algorithm development and I've generated code and run it on
>> a TI DSK6455 by creating a Code Composer Studio project and writing a
>> simple app to call the model step function.
>>
>> Obviously in reality the app will be much more complicated. It will need
>> to handle incoming video data and configuration data that will be
>> arriving via Serial Rapid I/O, it will be running multiple algorithms,
>> etc.
>>
>> We don't have a license for IDE Link or Target Support Package. Perhaps
>> we should?
>>
>> Any thoughts or pointers to further reading greatly appreciated!
>>
>> Thanks,
>> Matt
>
> Matt,
>
> I'd say the choice depends on:
> 1 - budget;
> 2 - resources available (man power AND Simulink/RTW/etc. skills and
> experience);
> 3 - how much and how well your real world system/task/problem can be
> represented in Simulink.
>
> In the past I've found (3) critical for custom apps - e.g.: explicit
> handling of pointers is completely alien to Simulink, while it may be very
> important for memory management in your app. Conversely, algorithms
> development is often made easier by Simulink block-diagram structure.
>
> If your app cannot be fully represented/described via Simulink
> block-diagrams, but you are happy with developing algorithms and
> autocoding them, you can just use RTW, defining algorithms' I/O in terms
> of Simulink Global/Exported signals and leaving all optimizations to the
> compiler.
>
> Otherwise, if Simulink is suitable for representing your entire app,
> subject to (1) you may try using Embedded Coder, which gives you more
> influence on the code generation process.
>
> For the rest:
> - High (1) Low(2) => besides tools, some consultancy time may help to
> speed-up development & to facilitate acquiring skills;
> - Low (1) High (2) => unlikely you're going to get beyond Simulink/RTW for
> individual algorithms; autogenerated code modules will have to be
> integrated - at build time - with hand-written modules.
>
> HTH
> Riccardo
>

> I'd say the choice depends on:
> 1 - budget;
> 2 - resources available (man power AND Simulink/RTW/etc. skills and experience);
> 3 - how much and how well your real world system/task/problem can be represented in Simulink.

That sounds like a good summary!

Most of us in the team our C programmers or hardware engineers will no real experience of MATLAB/Simulink/etc. The algorithms guys are experienced at developing algorithms in MATLAB/Simulink but I don't think any of them have been previously involved in a project that 'code gens'. In others words we have taken the decision to use code generation tools and we're all new to it!

We have an Embedded Coder license but not IDE Link or Target Support Package although extra cash could probably made available if justifiable.

I think the main problem is that my answer to 3 is "I'm not sure" and/or "it depends"!

I'm struggling to understand how to deal with a model where some parts will be implemented on a DSP and other parts on an FPGA (when I say model I don't necessarily mean that the whole thing is a single .mdl file).

I think we probably will seek advice from Mathworks support but I'm just trying to do as much preparation as possible!

Thanks,
Matt

"Matt " <remove.this.matt_d_br@hotmail.com> wrote in message <hdhbhq$l4j$1@fred.mathworks.com>...
> > I'd say the choice depends on:
> > 1 - budget;
> > 2 - resources available (man power AND Simulink/RTW/etc. skills and experience);
> > 3 - how much and how well your real world system/task/problem can be represented in Simulink.
>
> That sounds like a good summary!
>
> Most of us in the team our C programmers or hardware engineers will no real experience of MATLAB/Simulink/etc. The algorithms guys are experienced at developing algorithms in MATLAB/Simulink but I don't think any of them have been previously involved in a project that 'code gens'. In others words we have taken the decision to use code generation tools and we're all new to it!
>
> We have an Embedded Coder license but not IDE Link or Target Support Package although extra cash could probably made available if justifiable.
>
> I think the main problem is that my answer to 3 is "I'm not sure" and/or "it depends"!
>
> I'm struggling to understand how to deal with a model where some parts will be implemented on a DSP and other parts on an FPGA (when I say model I don't necessarily mean that the whole thing is a single .mdl file).
>
> I think we probably will seek advice from Mathworks support but I'm just trying to do as much preparation as possible!
>
> Thanks,
> Matt

The post just before yours includes some good suggestions.

It's very likely that your best approach is to use Simulink/RTW for algo development/prototyping - autocoding modules for testing and evaluation on real HW - and later proceed to integrate modules and optimize the full application.

In this case Simulink models will actually represent individual SW modules/functions/algorithms and will be autocoded independently. Then you'll have to develop a Build Environment which handles autocoded and hand-coded modules.

Different HW targets will require appropriate RTW/EC settings. Target Support might help - again depending on "how much" autocoding you may want/need.

Look at RTW examples of this sort of stuff (developing autocoded modules and integrating them with non-autocoded apps), there should be something. Use TMW support as well as CSSM. Work through some little autocoding pilot projects to gain experience.

The essential difference between fully hand-coded develpment process and this "hybrid" process involving autocoded-modules + hand-coded framework should be the speed-up in algorithm development and validation.

Once at this stage, you may investigate/evaluate whether it's worth trying to go further with autocoding.

HTH
Riccardo