Systems & Design
SPONSOR BLOG

Insurance, Doctors And ESL

In the design world we’ve been lucky so far, but our luck is running out.

popularity

By Jon McDonald

Return on investment is a subject that comes up frequently when people are thinking about adopting higher-level design approaches. After all, we are talking about adding work—we need to model, design, simulate and analyze the system. All of these tasks take time and cost money. So what are we getting in return?

Before we can think about the return, we have to identify what we are trying to accomplish by doing all of this work before starting the real implementation process of RTL design.

We want to predict the future. Before we implement the system we want to understand the implications of our design decisions. If we want to identify a return on investment for this extra work, we have to assume we would have made an incorrect decision without it. Now we are basing the ROI on the probability of making that incorrect decision, and we’ve started down that slippery slope of justifying the return based on statistics. Not that this can’t be done, but it involves much more complex math than we would typically want to see in bulletproof, management-accessible ROI. I believe we need to think about the justification for this investment in the same way we think about the justification for an insurance policy.

This reminds me of the doctor who explains to the patient the options to treat a medical condition without committing to a recommendation. Why can the patient make the decision better than the doctor who has had many years of training? It is because there is no way to prove that one course of treatment will always be better than another. The tradeoffs being made by the patient are subjective; they require a basic understanding of the options and impacts of choices beyond the field of medicine.

We are dealing with a similar problem when we make the jump from a natural language specification to the RTL implementation. The implementation choices made are subjective. It is expensive, difficult and sometimes impossible to prove the best implementation in RTL. Sometimes we can’t even determine if the implementation is acceptable at the RT level.

At the system level we have the flexibility to quantify some of these choices. We can’t prove everything, but we can quantify some of the implications of our selections. This gets to the core problem of an ROI evaluation: Through the ROI we look to prove that value is achieved. Nothing can prove that we could not have achieved the same result by jumping directly to RTL implementation, but system-level design provides incredibly valuable information that allows us to make educated design choices—insurance that we understand the implication of our choices.

So it comes down to how lucky you feel. If you’re really lucky, you may never need your insurance policies. If you’re design groups are lucky, you might get an acceptable implementation. But from what we are seeing in the design communities, our luck is running out. We need the insurance delivered by the additional information we can gain from the system level to guide our implementation choices.

–Jon McDonald is a technical marketing engineer for the design and creation business unit at Mentor Graphics.



Leave a Reply


(Note: This name will be displayed publicly)