Showing results for 
Search instead for 
Did you mean: 

MATRIXx code generation

MATRIXx code generation


How is AutoCode different from the code generation product of Simulink?

0 Kudos
Message 1 of 3

Re: MATRIXx code generation


Could you be more specific?  They are very similar in that they both generate code from their respective modeling programs.  MATRIXx's autocode supports ADA, C code generation, and more.  For more details, you may want to reference the Autocode manual here:

--Paul Mandeltort
Automotive and Industrial Communications Product Marketing
0 Kudos
Message 2 of 3

Re: MATRIXx code generation



Though I think that Paul answered your questions by pointing you in a direction, I felt that it would have been better answered with another question. The nature of the question should be understood before a response is formulated. In addition, I think it is important that the audience been known.


I take it you are a current user of MATRIXx and may have experience with other tools such as Simulink. I think you may have been looking to get a simple side by side comparison of features of the comparable tools in this case it would be AutoCode as compared to Real-time workshop, (RTW).


I would think that both would have their advantages, depending on your criteria. The weighting of the criteria would depend on your specific circumstances and biases. If you want to do a thorough investigation, I would do as Paul suggests, but I would also think about your specific uses, and needs customizability of the generated code, etc. I think it is important to start as early as possible and look at the evolution of the tools as well, this will give you some insight into the architecture though understanding the dominant complexities, and product quality attributes, that they were addressing as trade-offs were made at the time of the development of the underlying architecture. As you might imagine these tools have been developed over a period of many years with 10s of thousands of man years invested by their respective companies and used by different populations (demographics - here I mean primarily academic vs primarily industry).


Looking back, I think that originally MatLab was a public domain set of libraries. On the West Coast, we had people out of Stanford that were focused on Real-Time control software but liked to describe their software functions in block diagram format. You know the type. They worked on a suite of tools that ultimately became known as MATRIXx. This suite of tools included the kinds of things that control software people like to do, perform analysis, often linear, (Original MATRIXx), develop models and run time domain simulations, (SystemBuild), and generate the control code that they were going to embed. Though in academia, they started a company to purvey the tool suite, because the end product (the embedded software) was always in view, this tool was rapidly adopted by the aerospace industry (Boeing) and was used for the ISS, for example. This use by literally thousands of engineers in industry forced a particular evolution of the product. A good reference point for AutoCode specifically is a US Patent No.:4,796,179 Issued January 3, 1989, (Filed 1986) Inventors: I believe were Larry Lehman, Sunil Shah, Dave Varvel. As you might imagine it has evolved quite a bit since then. The overall software architecture, the design of these tool suites, is intimately related to their origins.


To understand the impact of software architecture on the constraints and limitations and robustness to change scenarios I would point you to a book that is quite insightful in this area: Evaluating Software Architectures: Methods and Case Studies by Paul Clements, Rick Kazman, and Mark Klein.


Concerning, the evolution of MatLab/Simulink/RTW (in contrast to Xmath/SystemBuild/AutoCode) the high-level functionality i.e. Analysis, Modeling and Simulation, and Code generation is the same. My perspective on the evolution is quite different and as a result I think the supporting software architecture and robustness to change scenarios is a difference that has resulted. Both products started from the Public Domain MatLab. I recall when MatLab was all that there was in the commercial incarnation, and a company was selling MatLab, MGA here on the East Coast, that also had a simulation product called ACSL (another simulation language). The main audience for MatLab was academia but as students moved from academia to industry, they like to continue to use the same tools. (What ever happened to Lotus 1, 2, 3? -- probably a story for a different Post). Like the SystemBuild incarnation, people started to think hey we are EEs, Aerospace Analysts and Automotive engineers. We think in Block diagrams not in software, we'd like to have a simulator that is graphical and hierarchal, viola - Simulink was born. I am sure that someone can add to this leap. Then shortly thereafter the need arose to take the controllers that were simulated in Simulink and generate code that would be suitable for real-time - again Viola - RTW was born.


If anyone can put together a timeline of both tools, I think that would be illustrative.


I think that looking at the origins you can see how the underlying architecture could be completely different and the implementation, functionality, and performance could vary, despite the fact that the highest levels of functionality are in fact quite common. Over time both tool suites have evolved as has their user base. The fundamental underlying architectures can't however change over night; it is that difference that allows capabilities to be added simply or only after great analysis.


Did I answer your question? A little?


I would be interested in alternate perspectives on my thoughts here.


Garrett Thurston
Phone: 781.993.5540
0 Kudos
Message 3 of 3