Posted by frank schirrmeister on July 10, 2008
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!
Patrick Sheridan
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.