Comments for The ESL Edge http://www.chipdesignmag.com/bailey ESL Design and Verification Tue, 06 Sep 2011 02:23:02 -0700 http://wordpress.org/?v=2.8.4 hourly 1 Comment on Grappling with Model-Based Design by Ken Karnofsky http://www.chipdesignmag.com/bailey/2011/09/01/grappling-with-model-based-design/comment-page-1/#comment-10315 Ken Karnofsky Tue, 06 Sep 2011 02:23:02 +0000 http://www.chipdesignmag.com/bailey/?p=94#comment-10315 Brian, You’re asking great questions about Model-Based Design. The Wikipedia page isn’t all that helpful in answering them, however. It’s not inaccurate, but it reflects a collection of perspectives and leaves the reader grasping for the essential reasons that lead companies adopt Model-Based Design. I’d rewrite a lot of it if it were up to me, but that’s not the way Wikipedia works. Abstraction is certainly a big part of the value of Model-Based Design. But it’s not a matter of graphical vs. textual. In Faraday’s case, they were able to use graphical languages (Simulink for time-driven systems, and Stateflow for finite state machines) as well as a textual language (MATLAB for algorithms). It’s not just one abstraction, but several domain-specific ones in one environment. Faraday engineers used these multidomain system models to simulate and optimize their design. Also, Model-Based Design isn’t simply about working at a higher level of abstraction, but also providing ways to leverage models with different levels of abstraction, such as reusing C-code or HDL models in a Simulink model. In Model-Based Design, the use of system models as executable specifications throughout the workflow is just as important as the abstraction. Faraday used automatic C code generation from their models to produce a programmer’s view of the design for software development and architecture exploration. They also used automatic HDL code generation to develop FPGA prototypes. Throughout the process, the system model allowed them to continuously test their design and implementation against the system specification they had captured in the model. Faraday’s results are impressive, but they’re not alone. In 2010, Embedded Market Forecasters (EMF) conducted an analysis to determine the impact of Model-Based Design on the total cost of development (TCD). Data was collected from companies worldwide from automotive, aerospace, communications, industrial automation, and medical industries. The results show that: 1) Development teams who used Model-Based Design had an average 37% lower TCD compared to teams that did not use Model-Based Design. 2) The number of developers used per project was smaller for Model-Based Design across all geographic areas and all vertical markets examined. 3) The percent of developer months lost to design cancellation or projects behind schedule was consistently less for Model-Based Design development projects across all verticals and geographic areas. You can view a webinar additional results from this study, presented by Dr. Jerry Krasner of EMF at http://www.mathworks.com/model-based-design. Ken Karnofsky MathWorks Brian,

You’re asking great questions about Model-Based Design. The Wikipedia page isn’t all that helpful in answering them, however. It’s not inaccurate, but it reflects a collection of perspectives and leaves the reader grasping for the essential reasons that lead companies adopt Model-Based Design. I’d rewrite a lot of it if it were up to me, but that’s not the way Wikipedia works.

Abstraction is certainly a big part of the value of Model-Based Design. But it’s not a matter of graphical vs. textual. In Faraday’s case, they were able to use graphical languages (Simulink for time-driven systems, and Stateflow for finite state machines) as well as a textual language (MATLAB for algorithms). It’s not just one abstraction, but several domain-specific ones in one environment. Faraday engineers used these multidomain system models to simulate and optimize their design. Also, Model-Based Design isn’t simply about working at a higher level of abstraction, but also providing ways to leverage models with different levels of abstraction, such as reusing C-code or HDL models in a Simulink model.

In Model-Based Design, the use of system models as executable specifications throughout the workflow is just as important as the abstraction. Faraday used automatic C code generation from their models to produce a programmer’s view of the design for software development and architecture exploration. They also used automatic HDL code generation to develop FPGA prototypes. Throughout the process, the system model allowed them to continuously test their design and implementation against the system specification they had captured in the model.

Faraday’s results are impressive, but they’re not alone. In 2010, Embedded Market Forecasters (EMF) conducted an analysis to determine the impact of Model-Based Design on the total cost of development (TCD). Data was collected from companies worldwide from automotive, aerospace, communications, industrial automation, and medical industries. The results show that:

1) Development teams who used Model-Based Design had an average 37% lower TCD compared to teams that did not use Model-Based Design.
2) The number of developers used per project was smaller for Model-Based Design across all geographic areas and all vertical markets examined.
3) The percent of developer months lost to design cancellation or projects behind schedule was consistently less for Model-Based Design development projects across all verticals and geographic areas.

You can view a webinar additional results from this study, presented by Dr. Jerry Krasner of EMF at http://www.mathworks.com/model-based-design.

Ken Karnofsky
MathWorks

]]> Comment on Grappling with Model-Based Design by Gene Bushuyev http://www.chipdesignmag.com/bailey/2011/09/01/grappling-with-model-based-design/comment-page-1/#comment-10292 Gene Bushuyev Sat, 03 Sep 2011 00:05:37 +0000 http://www.chipdesignmag.com/bailey/?p=94#comment-10292 It's definitely true that there is only one method known to mankind how to deal with growing complexities with the same resources (human brain), and that is increasing level of abstraction. But I don't believe the assumption that "it really doesn’t matter if you want to do that textually, graphically, or model-based" is valid. There are natural qualities of human brain that make one way of representing abstraction more suitable than another. I believe human brain is much better equipped to deal with images than with verbiage. It my unscientific experiments with GBL library I could definitely see how much easier it was for me to reason, modify, experiment, and remember the graphical representation of the system than the generated code. The reason I think is due to the fact that graphical representation is more compact than corresponding code, it clearly and explicitly expresses relationships and dependencies, which are implicit in code (name, position, type, scope, etc.). Graphical representation can be more easily customized to emphasize important and de-emphasize unimportant details. It also naturally discourages clutter, while a code mud is a common problem, which requires experience and discipline to avoid. Additionally, reasoning in terms of system behavior using event-based declarative programming techniques in model-based design is much easier than in terms of traditional imperative programming. The wonderful quality of the event is that it's completely oblivious to the consequences of its own cause, thus providing many blessings of very loose coupling. It’s definitely true that there is only one method known to mankind how to deal with growing complexities with the same resources (human brain), and that is increasing level of abstraction. But I don’t believe the assumption that “it really doesn’t matter if you want to do that textually, graphically, or model-based” is valid. There are natural qualities of human brain that make one way of representing abstraction more suitable than another. I believe human brain is much better equipped to deal with images than with verbiage. It my unscientific experiments with GBL library I could definitely see how much easier it was for me to reason, modify, experiment, and remember the graphical representation of the system than the generated code. The reason I think is due to the fact that graphical representation is more compact than corresponding code, it clearly and explicitly expresses relationships and dependencies, which are implicit in code (name, position, type, scope, etc.). Graphical representation can be more easily customized to emphasize important and de-emphasize unimportant details. It also naturally discourages clutter, while a code mud is a common problem, which requires experience and discipline to avoid. Additionally, reasoning in terms of system behavior using event-based declarative programming techniques in model-based design is much easier than in terms of traditional imperative programming. The wonderful quality of the event is that it’s completely oblivious to the consequences of its own cause, thus providing many blessings of very loose coupling.

]]> Comment on Am I Getting Old? by Harish http://www.chipdesignmag.com/bailey/2011/08/17/am-i-getting-old/comment-page-1/#comment-10222 Harish Fri, 19 Aug 2011 03:52:49 +0000 http://www.chipdesignmag.com/bailey/?p=89#comment-10222 I agree, Brian. I guess it is due to sense of loss of control ( technology taking over our lives). I agree, Brian. I guess it is due to sense of loss of control ( technology taking over our lives).

]]> Comment on Am I Getting Old? by Glenda http://www.chipdesignmag.com/bailey/2011/08/17/am-i-getting-old/comment-page-1/#comment-10218 Glenda Thu, 18 Aug 2011 01:48:16 +0000 http://www.chipdesignmag.com/bailey/?p=89#comment-10218 Cool! Cool!

]]> Comment on Amazing but True by Brian http://www.chipdesignmag.com/bailey/2011/08/04/amazing-but-true/comment-page-1/#comment-10203 Brian Mon, 15 Aug 2011 13:37:59 +0000 http://www.chipdesignmag.com/bailey/?p=86#comment-10203 What a tease Gerald. So we have to read the book to find out what is wrong with my statement. In the HW world, integration testing has been a big problem for many companies, not only because of the size of the verification space, but also because simulators run so slowly that the depth of test cases is severely limited. While emulators and FPGA prototyping help, these add another layer of complexity and cost to the problem which are out of reach to many smaller companies. What a tease Gerald. So we have to read the book to find out what is wrong with my statement. In the HW world, integration testing has been a big problem for many companies, not only because of the size of the verification space, but also because simulators run so slowly that the depth of test cases is severely limited. While emulators and FPGA prototyping help, these add another layer of complexity and cost to the problem which are out of reach to many smaller companies.

]]> Comment on Amazing but True by Gerald M. Weinberg http://www.chipdesignmag.com/bailey/2011/08/04/amazing-but-true/comment-page-1/#comment-10201 Gerald M. Weinberg Mon, 15 Aug 2011 03:56:24 +0000 http://www.chipdesignmag.com/bailey/?p=86#comment-10201 Brian, Good thoughts. It seems that much of what you are seeking has been researched for many years in the software world. You might look at my book, Perfect Software and Other Illusion about Testing. The book examines many of these issues and also supplies quite a few references. For example, it shows what's wrong with statements like "as system complexity grows and the amount of concurrency increases, the fraction of the total stimulus space that is actually covered is being reduced every day." You see, that "fraction" is zero and remains zero no matter how hard we try--but that doesn't mean we should stop trying. It just means we need to be very careful in designing our goals for testing. Brian,
Good thoughts.

It seems that much of what you are seeking has been researched for many years in the software world. You might look at my book, Perfect Software and Other Illusion about Testing.

The book examines many of these issues and also supplies quite a few references.

For example, it shows what’s wrong with statements like “as system complexity grows and the amount of concurrency increases, the fraction of the total stimulus space that is actually covered is being reduced every day.”

You see, that “fraction” is zero and remains zero no matter how hard we try–but that doesn’t mean we should stop trying. It just means we need to be very careful in designing our goals for testing.

]]> Comment on Amazing but True by Gaurav Jalan http://www.chipdesignmag.com/bailey/2011/08/04/amazing-but-true/comment-page-1/#comment-10177 Gaurav Jalan Fri, 05 Aug 2011 11:21:07 +0000 http://www.chipdesignmag.com/bailey/?p=86#comment-10177 Hi Brian, That's a thought provoking post :) I had blogged on a similar philosophy some time back. Check it out! http://whatisverification.blogspot.com/2010/10/proof-of-no-bug-or-no-proof-of-bug.html Amazing but true! Thanks & Regards, Gaurav Jalan Hi Brian,

That’s a thought provoking post :)
I had blogged on a similar philosophy some time back. Check it out!
http://whatisverification.blogspot.com/2010/10/proof-of-no-bug-or-no-proof-of-bug.html

Amazing but true!

Thanks & Regards,
Gaurav Jalan

]]> Comment on To the Virtual Prototype and Beyond by Brian http://www.chipdesignmag.com/bailey/2011/07/21/to-the-virtual-prototype-and-beyond/comment-page-1/#comment-10146 Brian Wed, 27 Jul 2011 14:21:15 +0000 http://www.chipdesignmag.com/bailey/?p=80#comment-10146 There are two sets of costs - the model development costs and the model utilization costs. Model development costs are probably born by the hardware group and given that this is quite possibly a model they will be using for architectural exploration or even high-level synthesis, then yes, they will pay traditional EDA costs for them. The costs to run the models have to be inline with the costs that the software group traditionally expects - if they continue to just use them for debug. However, if the models enable them to do things that they could never do before and in turn make the product better - more competitive - then it is possible that they could expect more for them. There are some software groups who are willing to pay for emulations and FPGA prototyping so I think to say that tools have to be almost free is perhaps clinging on to a cliche of the past that may be changing. People will pay for value. Most existing software tools are commodities. There are two sets of costs – the model development costs and the model utilization costs. Model development costs are probably born by the hardware group and given that this is quite possibly a model they will be using for architectural exploration or even high-level synthesis, then yes, they will pay traditional EDA costs for them. The costs to run the models have to be inline with the costs that the software group traditionally expects – if they continue to just use them for debug. However, if the models enable them to do things that they could never do before and in turn make the product better – more competitive – then it is possible that they could expect more for them. There are some software groups who are willing to pay for emulations and FPGA prototyping so I think to say that tools have to be almost free is perhaps clinging on to a cliche of the past that may be changing. People will pay for value. Most existing software tools are commodities.

]]> Comment on To the Virtual Prototype and Beyond by Brian http://www.chipdesignmag.com/bailey/2011/07/21/to-the-virtual-prototype-and-beyond/comment-page-1/#comment-10145 Brian Wed, 27 Jul 2011 14:14:44 +0000 http://www.chipdesignmag.com/bailey/?p=80#comment-10145 In response to Gaurav Jalan: Exactly, plus with power management hardware that is controlled by software, the software has to be optimizing itself in a dynamic manner. In response to Gaurav Jalan: Exactly, plus with power management hardware that is controlled by software, the software has to be optimizing itself in a dynamic manner.

]]> Comment on To the Virtual Prototype and Beyond by Everett Lumpkin http://www.chipdesignmag.com/bailey/2011/07/21/to-the-virtual-prototype-and-beyond/comment-page-1/#comment-10139 Everett Lumpkin Tue, 26 Jul 2011 00:34:35 +0000 http://www.chipdesignmag.com/bailey/?p=80#comment-10139 Can virtual prototyping for software make inroads at the costs (for models and tools) demanded by EDA companies? Embedded development in general expects tools at price points of less than $1000 (compilers, debuggers, lint tools). I watched in horror as a company imploded man-years of model development and microcontroller supplier relationships for the want of a license renewal. The benefits (quality and time) and cost savings spoke for themselves, but the capital expenses just didn't compare against the "normal" expenses associated with going backwards to do things the old way. Can virtual prototyping for software make inroads at the costs (for models and tools) demanded by EDA companies? Embedded development in general expects tools at price points of less than $1000 (compilers, debuggers, lint tools). I watched in horror as a company imploded man-years of model development and microcontroller supplier relationships for the want of a license renewal. The benefits (quality and time) and cost savings spoke for themselves, but the capital expenses just didn’t compare against the “normal” expenses associated with going backwards to do things the old way.

]]>