Teach your children math … and model based design

Teach your children well,
Their father’s hell did slowly go by,
And feed them on your dreams
The one they picked, the one you’ll know by.

Crosby Stills Nash & Young

Besides that I like the old Crosby, Stills, Nash & Young song a lot, the thoughts on this post had to settle a while for me. Hence this is DAC related although it seems quite a while ago already.

On my last day at DAC I took some time off from my own DAC duties and watched the key note of Jack Little, president and co-founder of The MathWorks. His keynote address was titled “Idea to Implementation: A Difference Perspective on System Design” and he discussed the use of Model-Based Design to solve the growing challenges of electronic systems and embedded software development.

He opened his address with a story of the little village called Mathville (well, it looked a bit like Natick to me J), which was disconnected from the tangential highway right next to it. No exit. No profit from traffic potentially coming to them.

Jack then talked about Engineering Math, linear algebra, static relationships, differential equations – continuous and discrete time – and asked what they have in common. Well, they all are ubiquitous and used across various industries, professions and applications. Let’s teach your children math to be prepared … and computers enable widespread use of Math. A fascinating graph he used is shown here, in which the progression of computer performance is shown since the 1984 breakthrough introduction of personal computers. The data speaks for itself.

The problems with current development flows were nicely illustrated with Flight 501 of Ariane 5, which impressively failed because the control of the nozzle control failed due to mapping the original floating point data to 16bit integer and causing an arithmetic overflow. As a solution Jack introduced model based design with automatic code generation.

At this point I realized that I have not a good enough understanding what model based design is. Is it just graphics on top of the code users write? Does there has to be a large library of models enabling re-use? Are the different levels of models? It looks like all of the above. When searching around I found in an article authored by the Mathworks the following description:

“Model-Based Design [enables] a hierarchical design process in which the entire design is initially defined at a conceptual level and detail is added as necessary to deliver the needed functionality. The model is used to define specifications, evaluate design and system performance, automatically generate code, perform hardware-in-the-loop testing, and create a software-based test harness for testing production hardware. This approach can substantially reduce development time by rapidly leading to complete and functional proof-of-concept designs and enabling rapid design iterations and parameter optimization through a unified design, simulation, and test environment.”

This sounds very much like different levels of abstraction again, adding detail where necessary. The results presented in Jack Little’s key note are quite impressive. He showed how models are used to automatically generate 1,000,000 lines of code by Honeywell for airplane flight control systems, as well as how Toyota and Visteon automatically generate code which is more compact than hand coded software in automotive applications. Equally important, because of the coding phase going away, Toyota Denso was able to significantly shorten time to market as the graph on the left shows nicely. They expect even further improvement because of the impact of model based design on verification.

That all said – with impressive results in model based software design – Jack brought the Mathville introduction nicely home at the end by outlining that Mathville is now also connected to the hardware world via a direct exit to the “EDA highway”. This of course is an area in which Synopsys already plays for quite some time with our System Studio product for model based design of digital signal processing algorithms. For the model based implementation of algorithms of that type tools like Synplify DSP® can be used.

In closing – I had further discussions about model based design with our Synopsys Fellow Mike Keating and he had an interesting perspective on the use of graphical representations. He argues that because textual entry is one-dimensional in contrast to two dimensional graphical entry, it is easier to enter data as text and to reason about it using the graphical representation. I fully can relate to that view. When doing code reviews way back when I was designing chips, I always re-constructed graphical state charts from textual Verilog to be able to reason about the functionality of the state machine. However, model based design seems to also take into account the refinement process of adding more detail to an originally more abstract diagram.

So my conclusion for now is that in refinement from one abstraction level to the next more detailed one, graphical refinement will work fine. However, when being at a specific abstraction level, textual entry using an expressive language is more elegant than graphical design entry.

Does this make sense? I am looking forward to your thoughts and comments!