Abstract
Matlab & Simulink is is widely used as a defacto standard to design industrial applications, video coding & decoding, and signal processing applications. However, with the spectacular increase in the number of the cores available in hardware platforms over these last years, passing from Simulink to multi-core execution becomes more and more complex. In this context, several researches are done to take benefit from the high degree of parallelism and to perform multi-core programming of Simulink applications. In this paper, we present an automated method for transforming hierarchical Simulink applications to embedded parallel software implementation. Our method consists of using IBSDF (Interfaced based Synchronous Dataflow) as an intermediate representation to extract parallelism. Moreover, our approach permits preserving synchronous semantics and hierarchical behavior of the Simulink model. The model-based approach makes it possible to verify the key properties of the system at compile-time, such as deadlock freeness and memory boundedness. The method has been implemented as an extension of the rapid prototyping tool named Preesm. Experiments show that our proposal gives, as a transformation result, a schedulable IBSDF graph equivalent in size to the Simulink model and allows better multi-core implementation performance than Matlab & Simulink sequential execution.
Highlights
Synchronous data-flow SDF, introduced by Lee and Messerschmitt [9, 10], are MoC providing high level design and implementation of embedded programs, which are notably popular for specifying digital signal processing applications
An embedded signal processing application is used to illustrate the efficiency of our approach in a realistic setting
We have described an efficient approach to automatically optimize and transform hierarchical Simulink to multi-core execution
Summary
2.1 Synchronous Data-flow and InterfaceBased Synchronous Data-flowSynchronous data-flow SDF, introduced by Lee and Messerschmitt [9, 10], are MoC providing high level design and implementation of embedded programs, which are notably popular for specifying digital signal processing applications.An SDF graph G = (A, F, P ) consists of a set of actors A interconnected by a set of FiFo F carrying data tokens and a set of port P used as anchors for FiFo connection such that:• A = (a1, a2, a3, ...) is the set of actors that consume and/or produce data tokens.• F = (F1, F2, F3, ...) is the set of channels carrying data streams.• P = (inP, outP ) is the port set of an actor ai.• inP (ai) = (inP1(ai), inP2(ai), inP3(ai), ...) is the set of input ports of an actor ai.• outP (ai) = (outP1(ai), outP2(ai), outP3(ai), ...) is the set of output ports of an actor (ai).• IN (ai) = (in1(ai), in2(ai), in3(ai), , ...) is the set of data consumed by the different ai input ports at each firing.• OU T (ai) = (out1(ai), out2(ai), out3(ai), ...) is the set of data produced by the different ai output ports.• d(ai, aj) is the amount of initial tokens on a FiFo F connecting the actors ai and aj , we refer to it as a delay. The delay allows to represent data dependencies between successive graph iteration [23] and perform analysis. A graph iteration is the minimal fixed sequence of actor firings that can be repeated indefinitely to execute the graph.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callMore From: Universal Journal of Electrical and Electronic Engineering
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
