{"id":197998,"date":"2026-03-11T12:11:50","date_gmt":"2026-03-11T12:11:50","guid":{"rendered":"https:\/\/innovationspace.ansys.com\/knowledge\/?post_type=topic&p=197998"},"modified":"2026-03-11T13:14:04","modified_gmt":"2026-03-11T13:14:04","slug":"generating-efficient-code-from-a-swan-model","status":"publish","type":"topic","link":"https:\/\/innovationspace.ansys.com\/knowledge\/forums\/topic\/generating-efficient-code-from-a-swan-model\/","title":{"rendered":"Generating efficient code from a Swan model"},"content":{"rendered":"

\n <\/p>\n

Introduction<\/h3>\n

In this post, we’ll take a closer look at one of the key improvements in Scade One 2026 R1: the Swan code generator. This tool converts Swan models into efficient, portable C code, and with the latest release, it’s now even better at optimizing performance of the generated code.<\/p>\n

In a previous blog post<\/a>, for the first release of Scade One, we introduced the Swan language, used for modeling in Scade One. One of the specificities of Swan compared to traditional programming languages like C\/C++ or Rust is that it is declarative<\/em>. It means that a Swan model describes what<\/em> to compute, using equations and a mathematical definition of the outputs. The code generator takes care of how<\/em> to compute the results, translating the high-level description in the Swan model into imperative C code. In particular, the code generator needs to allocate variables and memory and decide in which order to perform the various operations. This approach makes it possible to build complex applications using a high-level language like Swan, even if you’re not a seasoned programmer, while still delivering performance that’s on par with hand-written C code.<\/p>\n

\n
\n Figure 1– Generating imperative code from a declarative model<\/em>\n<\/p>\n

In this blog, we’ll show various examples to illustrate how the Swan code generator generates efficient C code. These examples are also a good way to illustrate interesting use cases for the new constructs introduced in Swan. Finally, we’ll preview another new feature in 2026 R1, which enables more control over the allocation of memory in the generated code, when using external libraries like BLAS and when performance is key. <\/p>\n

Implementing a convolution on a matrix<\/h3>\n

Let’s start by looking at a convolution algorithm. We have already shown in a previous blog<\/a> how to implement convolution in Swan using nested forward iterations (the new loop-like construct introduced in Swan). Here, we will use an alternative way that only makes sense in a declarative language like Swan and is very different from an imperative implementation.<\/p>\n

In this example, the Convol2D<\/code> operator takes as input a square matrix I<\/code> (of size N by N) and returns a matrix C<\/code> (of size (N-2) by (N-2)), where each element is obtained by doing a weighted average of the neighbors using the coefficients in matrix K<\/code>.<\/p>\n

\n
\n <\/em>\n<\/p>\n

This is done by using the Pack2D<\/code> operator to create an intermediate matrix (of size (N-2) by (N-2)), where each element is the matrix of the neighbors in the input matrix I. Then, we just iterate on this matrix and apply the WeightedAvg<\/code> operator on each sub-matrix. It may seem counter-intuitive to compute this huge intermediate matrix (of type int32^P^P^(N-2)^(N-2)<\/code> !). It works because this matrix is never actually created in the generated code. The code generator transforms the iteration on this intermediate matrix into an iteration on the input matrix I, with the necessary index adaptations:<\/p>\n

<\/p>\n

\n
<\/span>\/* Convol2D::Convol2D_8 *\/<\/span>\r\nvoid<\/span> <\/span>Convol2D_8_Convol2D<\/span>(\r\n\u00a0 <\/span>\/* I *\/<\/span>\r\n\u00a0 <\/span>const<\/span> <\/span>array_int32_8_8 <\/span>*<\/span>I,\r\n\u00a0 <\/span>\/* K *\/<\/span>\r\n\u00a0 <\/span>const<\/span> <\/span>array_int32_3_3 <\/span>*<\/span>K,\r\n\u00a0 <\/span>\/* C *\/<\/span>array_int32_6_6 <\/span>*<\/span> <\/span>restrict<\/span> <\/span>C)\r\n{\r\n\u00a0 <\/span>swan_size <\/span>i1;\r\n\u00a0 <\/span>swan_size <\/span>j1;\r\n\u00a0 <\/span>swan_size <\/span>k1;\r\n\u00a0 <\/span>swan_size <\/span>i11;\r\n\r\n\u00a0 <\/span>for<\/span> <\/span>(i1 <\/span>=<\/span> <\/span>0<\/span>; <\/span>i1 <\/span><<\/span> <\/span>6<\/span>; <\/span>i1++<\/span>) <\/span>{\r\n\u00a0 \u00a0 <\/span>for<\/span> <\/span>(j1 <\/span>=<\/span> <\/span>0<\/span>; <\/span>j1 <\/span><<\/span> <\/span>6<\/span>; <\/span>j1++<\/span>) <\/span>{\r\n\u00a0 \u00a0 \u00a0 <\/span>(*<\/span>C)[i1][j1] <\/span>=<\/span> <\/span>swan_lit_int32(0<\/span>);\r\n\u00a0 \u00a0 \u00a0 <\/span>for<\/span> <\/span>(k1 <\/span>=<\/span> <\/span>0<\/span>; <\/span>k1 <\/span><<\/span> <\/span>3<\/span>; <\/span>k1++<\/span>) <\/span>{\r\n\u00a0 \u00a0 \u00a0 \u00a0 <\/span>for<\/span> <\/span>(i11 <\/span>=<\/span> <\/span>0<\/span>; <\/span>i11 <\/span><<\/span> <\/span>3<\/span>; <\/span>i11++<\/span>) <\/span>{\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 <\/span>(*<\/span>C)[i1][j1] <\/span>=<\/span> <\/span>(*<\/span>C)[i1][j1] <\/span>+<\/span> <\/span>(*<\/span>I)[k1 <\/span>+<\/span> <\/span>i1][i11 <\/span>+<\/span> <\/span>j1] <\/span>*<\/span> <\/span>(*<\/span>K)[k1][i11];\r\n\u00a0 \u00a0 \u00a0 \u00a0 <\/span>}\r\n\u00a0 \u00a0 \u00a0 <\/span>}\r\n\u00a0 \u00a0 <\/span>}\r\n\u00a0 <\/span>}\r\n}\r\n<\/pre>\n<\/div>\n
Another advantage of this approach is that the Pack2D<\/code> operator can be used as a library operator, without having to know how it’s implemented (using a non-trivial combination of pack<\/code> and transpose<\/code>). But, in the end, the code generated from this high-level description is as efficient as a direct implementation using nested for loops in C.<\/p>\n
Did you know?<\/em> If you want to learn more about Swan, you can look at the examples provided with Scade One. The corresponding user documentation<\/a> is available for free, without any registration, on the Ansys Help website.<\/p>\n
Computing a moving average of a signal<\/h3>\n
Now let’s switch to another example. The goal here is to compute the moving average of the last n values of an input flow. This is easily implemented in Swan using the temporal window operator window<\/code>. It returns an array of the last n values of the input flow, where the element at index i<\/em> is the input value i+1<\/em> cycles ago. Then, we just compute the average of the elements by iterating on the array:<\/p>\n
\n    
\n    <\/em>\n<\/p>\n
This example is straightforward, but it’s more interesting to look at the generated code:<\/p>\n
<\/p>\n
\n
<\/span>\/* MovingAvg::MovingAvg *\/<\/span>\r\nvoid<\/span> <\/span>MovingAvg_MovingAvg<\/span>(\r\n\u00a0 <\/span>\/* x *\/<\/span>swan_float32 <\/span>x,\r\n\u00a0 <\/span>\/* avg *\/<\/span>swan_float32 <\/span>*<\/span> <\/span>restrict<\/span> <\/span>avg,\r\n\u00a0 <\/span>outC_MovingAvg_MovingAvg <\/span>*<\/span> <\/span>restrict<\/span> <\/span>outC)\r\n{\r\n\u00a0 <\/span>swan_size <\/span>i1;\r\n\r\n\u00a0 <\/span>*<\/span>avg <\/span>=<\/span> <\/span>swan_lit_float32(0.0<\/span>);\r\n\u00a0 <\/span>for<\/span> <\/span>(i1 <\/span>=<\/span> <\/span>0<\/span>; <\/span>i1 <\/span><<\/span> <\/span>5<\/span>; <\/span>i1++<\/span>) <\/span>{\r\n\u00a0 \u00a0 <\/span>*<\/span>avg <\/span>=<\/span> <\/span>*<\/span>avg <\/span>+<\/span> <\/span>outC-><\/span>window.items[(-<\/span> <\/span>i1 <\/span>+<\/span> <\/span>(outC-><\/span>window.idx <\/span>+<\/span> <\/span>4<\/span>)) <\/span>%<\/span> <\/span>5<\/span>];\r\n\u00a0 <\/span>}\r\n\u00a0 <\/span>outC-><\/span>window.items[outC-><\/span>window.idx] <\/span>=<\/span> <\/span>x;\r\n\u00a0 <\/span>outC-><\/span>window.idx <\/span>=<\/span> <\/span>(outC-><\/span>window.idx <\/span>+<\/span> <\/span>1<\/span>) <\/span>%<\/span> <\/span>5<\/span>;\r\n}\r\n<\/pre>\n<\/div>\n
The window<\/code> operator is implemented as a circular buffer: at each cycle, the current value is stored in buffer window.items<\/code> at index window.idx<\/code>, and the index is incremented (modulo the size of the buffer). As we have seen before, the output array of the window is never actually built. Any access or iteration on this array is transformed into an access or iteration on the circular buffer. <\/p>\n
Designing digital filters in Swan<\/h3>\n
The temporal window<\/code> operator is also a perfect fit for implementing digital filters. Let us first consider a Finite Impulse Response (FIR) digital filter, defined by:<\/p>\n
$$y=\\sum_{k=0}^{N}{B\\left[k\\right]\\cdot x_{n-k}}$$<\/p>\n
Since window<\/code> gives access to the N past values of a flow (in this formula $x_{n-1}, \\ldots, x_{n-N}$) but not to the current one ($x_{n}$), we put the term $B\\left[0\\right]\\cdot x_{n}$  out of the sum to isolate what can be computed as an iteration on the window :<\/p>\n
$$y=B\\left[0\\right]\\cdot x_n+\\sum_{k=1}^{N}{B\\left[k\\right]\\cdot x_{n-k}}$$<\/p>\n
Supposing the filter initializes with zero, the formula above can be expressed as:<\/p>\n
\n    
\n    <\/em>\n<\/p>\n
Note that this implementation is parametrized by the size N of the input array; this is an improvement over the Scade 6 language, where it was not possible to create such a generic implementation using only the fby<\/code> operator. The code generated in this example is again very efficient:<\/p>\n
<\/p>\n
\n
<\/span>\/* Filters::FIR_filter *\/<\/span>\r\nvoid<\/span> <\/span>FIR_filter_Filters<\/span>(\r\n\u00a0 <\/span>\/* x *\/<\/span>swan_float32 <\/span>x,\r\n\u00a0 <\/span>\/* B *\/<\/span>\r\n\u00a0 <\/span>const<\/span> <\/span>array_float32_4 <\/span>*<\/span>B,\r\n\u00a0 <\/span>\/* y *\/<\/span>swan_float32 <\/span>*<\/span> <\/span>restrict<\/span> <\/span>y,\r\n\u00a0 <\/span>outC_FIR_filter_Filters <\/span>*<\/span> <\/span>restrict<\/span> <\/span>outC)\r\n{\r\n\u00a0 <\/span>swan_size <\/span>i1;\r\n\r\n\u00a0 <\/span>*<\/span>y <\/span>=<\/span> <\/span>(*<\/span>B)[0<\/span>] <\/span>*<\/span> <\/span>x;\r\n\u00a0 <\/span>for<\/span> <\/span>(i1 <\/span>=<\/span> <\/span>0<\/span>; <\/span>i1 <\/span><<\/span> <\/span>3<\/span>; <\/span>i1++<\/span>) <\/span>{\r\n\u00a0 \u00a0 <\/span>*<\/span>y <\/span>=<\/span> <\/span>*<\/span>y <\/span>+<\/span> <\/span>(*<\/span>B)[i1 <\/span>+<\/span> <\/span>1<\/span>] <\/span>*<\/span> <\/span>outC-><\/span>window.items[(-<\/span> <\/span>i1 <\/span>+<\/span> <\/span>(outC-><\/span>window.idx <\/span>+<\/span> <\/span>2<\/span>)) <\/span>%<\/span> <\/span>3<\/span>];\r\n\u00a0 <\/span>}\r\n\u00a0 <\/span>outC-><\/span>window.items[outC-><\/span>window.idx] <\/span>=<\/span> <\/span>x;\r\n\u00a0 <\/span>outC-><\/span>window.idx <\/span>=<\/span> <\/span>(outC-><\/span>window.idx <\/span>+<\/span> <\/span>1<\/span>) <\/span>%<\/span> <\/span>3<\/span>;\r\n}\r\n<\/pre>\n<\/div>\n
Controlling memory allocation in the generated code<\/h3>\n
Introducing memory control annotations<\/h5>\n
As we have seen in the previous examples, the Swan code generator takes care of generating efficient code from Swan models. To do that, it follows a number of optimizations and heuristics. Most of the time that is enough, but for more advanced use cases, it is not. <\/p>\n
A new feature in Scade One 2026 R1 allows more control on memory allocated by the code generator. The idea is to add annotations to the model that correspond to constraints on the memory allocation in the generated code. These annotations guide the code generator to generate more efficient code and enable new use cases as we’ll soon see. The code generator may fail to generate code if the constraints cannot be satisfied and will then raise an error message.<\/p>\n
\n    
\n    Figure 2– Using annotations to control memory in the generated code<\/em>\n<\/p>\n
It is important to understand that these annotations do not change the nature of the language: it is still a declarative language, and the behavior of models is the same with or without annotations.<\/p>\n
Using annotations to leverage efficient libraries<\/h5>\n
The first use case for these new annotations is to efficiently use existing C code, in particular libraries like BLAS<\/a>. Although Swan generated code is efficient, it will never be as efficient as such libraries, that are hand-tuned or use specific compiler or hardware features. <\/p>\n
Let us consider the axpy<\/code> function of the BLAS library which computes a vector-scalar product and adds the result to the input vector:<\/p>\n
$$y := a*x + y$$<\/p>\n
Swan allows using such external (or imported) C code by having a Swan operator declaration with no matching definition:<\/p>\n
<\/p>\n
\n
<\/span>function<\/span> saxpy&lt;&zwj;&lt;&zwj;N&zwj;&gt;&zwj;&gt;(a: float64<\/span>; x: float64<\/span>^<\/span>N; y: float64<\/span>^<\/span>N)\r\n  returns<\/span> (z: float64<\/span>^<\/span>N);\r\n<\/pre>\n<\/div>\n
The expected signature of such a function (that must be implemented by the user) is:<\/p>\n
<\/p>\n
\n
<\/span>\/* Imported::saxpy *\/<\/span>\r\nextern<\/span> <\/span>void<\/span> <\/span>saxpy_Imported<\/span>(\r\n\u00a0 <\/span>\/* a *\/<\/span> <\/span>swan_float64 <\/span>a,\r\n\u00a0 <\/span>\/* x *\/<\/span> <\/span>const<\/span> <\/span>array_float64_100 <\/span>*<\/span>x,\r\n\u00a0 <\/span>\/* y *\/<\/span> <\/span>const<\/span> <\/span>array_float64_100 <\/span>*<\/span>y,\r\n\u00a0 <\/span>\/* z *\/<\/span> <\/span>array_float64_100 <\/span>*<\/span> <\/span>restrict<\/span> <\/span>z,\r\n\u00a0 <\/span>outC_saxpy_Imported <\/span>*<\/span> <\/span>restrict<\/span> <\/span>outC);\r\n<\/pre>\n<\/div>\n
The important point here is that the input arrays x<\/code> and y<\/code> and the output array z<\/code> are separate variables. This does not correspond to the API of the BLAS function, which updates the y input in-place. Until now, there was no other solution than to write a wrapper around the BLAS call that would perform an array copy, to match the signature expected by the code generator.<\/p>\n
The new annotations introduced in Scade One 2026 R1 allow to constrain the code generator, so that the imported function can modify the input in-place:<\/p>\n
<\/p>\n
\n
<\/span>function<\/span> blas_saxpy&lt;&zwj;&lt;&zwj;N&zwj;&gt;&zwj;&gt;(a: float64<\/span>; x: float64<\/span>^<\/span>N; y *<\/span>: float64<\/span>^<\/span>N)\r\n  returns<\/span> (z at y: float64<\/span>^<\/span>N);\r\n<\/pre>\n<\/div>\n
The first annotation (y *<\/code>) means that there should be no dedicated memory location for y<\/code>. The second one (z at y<\/code>) means that z<\/code> should be stored at the same location as y<\/code>. The expected C signature for this annotated imported operator is:<\/p>\n
<\/p>\n
\n
<\/span>\/* Blas::blas_saxpy *\/<\/span>\r\nextern<\/span> <\/span>void<\/span> <\/span>blas_saxpy_Blas<\/span>(\r\n\u00a0 <\/span>\/* a *\/<\/span> <\/span>swan_float64 <\/span>a,\r\n\u00a0 <\/span>\/* x *\/<\/span> <\/span>const<\/span> <\/span>array_float64_100 <\/span>*<\/span>x,\r\n\u00a0 <\/span>\/* y *\/<\/span> <\/span>array_float64_100 <\/span>*<\/span> <\/span>restrict<\/span> <\/span>y,\r\n\u00a0 <\/span>outC_blas_saxpy_Blas <\/span>*<\/span> <\/span>restrict<\/span> <\/span>outC);\r\n<\/pre>\n<\/div>\n
We can see that the output z<\/code> has disappeared: the code generator will now read the output z<\/code> in the memory location storing y<\/code>. Of course, using this function impacts the generated code. For instance, the code generator must remember that after calling blas_saxpy<\/code>, the array used as input is overwritten, so any access to this array must be done before calling blas_saxpy<\/code>.<\/p>\n
This is the first release of this new feature. We’ll have more use cases to show on that topic in future releases (and future blogs). Stay tuned!<\/p>\n
Explore further<\/h3>\n
In this article, we have illustrated how the Swan code generator takes a high-level Swan model and turns it into efficient, portable C code. We have focused in particular on operators manipulating arrays and matrices, where the code generator avoids unnecessary copies or intermediate arrays and generates efficient index computations.  You can download the examples from here<\/a>.<\/p>\n
If you’d like to learn more about Ansys Scade One, we’d love to hear from you! Get in touch on our product page<\/a>.<\/p>\n
About the author<\/h3>\n\n\n
\n
\n    
\n                <\/em>\n<\/p>\n<\/td>\n
\n
C\u00e9dric Pasteur<\/strong> (LinkedIn<\/a>) is a Senior Product Manager at Ansys. He has been working on Scade One, Ansys’ latest-generation model-based embedded software development product, since its inception. He specializes in programming language theory and its application to safe embedded systems.<\/p>\n<\/td>\n<\/tr>\n<\/table>\n","protected":false},"template":"","class_list":["post-197998","topic","type-topic","status-publish","hentry","topic-tag-c","topic-tag-code","topic-tag-performance","topic-tag-scade-one","topic-tag-swan"],"aioseo_notices":[],"acf":[],"custom_fields":[{"0":{"_edit_lock":["1774542139:1769"],"_edit_last":["1769"],"_aioseo_title":[null],"_aioseo_description":[null],"_aioseo_keywords":["a:0:{}"],"_aioseo_og_title":[null],"_aioseo_og_description":[null],"_aioseo_og_article_section":[""],"_aioseo_og_article_tags":["a:0:{}"],"_aioseo_twitter_title":[null],"_aioseo_twitter_description":[null],"filter_by_optics_product":["Lumerical"],"_filter_by_optics_product":["field_64fb192ba3121"],"application_name":[""],"_application_name":["field_64a80903c8e15"],"family":[""],"_family":["field_64a809229a857"],"siebel_km_number":[""],"_siebel_km_number":["field_63ecbffce60db"],"salesforce_km_number":[""],"_salesforce_km_number":["field_63ecc018e60dc"],"km_published_date":[""],"_km_published_date":["field_64c77704499dd"],"product_version":[""],"_product_version":["field_64c776cb4fd2e"],"_bbp_forum_id":["27825"],"_bbp_topic_id":["198004"],"_bbp_author_ip":["87.190.19.71"],"_bbp_last_reply_id":["0"],"_bbp_last_active_id":["197999"],"_bbp_last_active_time":["2026-03-11 12:11:50"],"_bbp_reply_count":["0"],"_bbp_reply_count_hidden":["0"],"_bbp_voice_count":["0"],"_btv_view_count":["214"],"_bbp_likes_count":["4"]},"test":"solution"}],"_links":{"self":[{"href":"https:\/\/innovationspace.ansys.com\/knowledge\/wp-json\/wp\/v2\/topics\/197998","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/innovationspace.ansys.com\/knowledge\/wp-json\/wp\/v2\/topics"}],"about":[{"href":"https:\/\/innovationspace.ansys.com\/knowledge\/wp-json\/wp\/v2\/types\/topic"}],"version-history":[{"count":6,"href":"https:\/\/innovationspace.ansys.com\/knowledge\/wp-json\/wp\/v2\/topics\/197998\/revisions"}],"predecessor-version":[{"id":198004,"href":"https:\/\/innovationspace.ansys.com\/knowledge\/wp-json\/wp\/v2\/topics\/197998\/revisions\/198004"}],"wp:attachment":[{"href":"https:\/\/innovationspace.ansys.com\/knowledge\/wp-json\/wp\/v2\/media?parent=197998"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}