Why Should A Decision Be Delayed?

By Jon McDonald
Way back in college when I first learned about “delayed binding” I was absolutely ecstatic. In its most general interpretation this is not just a software concept. It’s a way of life. The important part of the concept is to understand that a decision or an action should not be taken until it needs to be taken.

This is a relatively simple concept with very broad implications and wide areas of application. It can be very frustrating to some people, including my wife. She sees it as procrastination. But from my perspective it is actually a very proactive approach. I would prefer to delay an action as long as possible, gathering additional information, continually evaluating the potential options and only committing to a particular choice when it is actually required to make that commitment.

I have had a number of discussions with various customers recently that has brought me back to the value of this philosophy as it can be applied to ESL design processes. A wide range of customers are applying ESL design techniques and attempting to link the various portions of their engineering processes. They often look at starting with systems engineers capturing the initial model of the system in UML or SysML. This initial model may then feed into the architecture design team as an abstract transaction level model, often in SystemC.

The architecture design team can refine this model, generally getting to a loosely timed (LT) SystemC TLM2.0 representation. This functional representation of the architecture is the starting point for virtual prototyping and architectural exploration. The LT TLM representation can be refined with target implementation characteristics to an approximately timed (AT) model which then becomes the reference point for the RTL implementation.

At each stage along this process it is absolutely critical that we apply the philosophy of delayed binding to the models we are creating and the decisions we are making. In my mind this is the art of the system-level engineering process. We must understand what level of detail and what level of accuracy are required at each level. Making an implementation decision too early in the process can force a system implementation down a path with little chance of delivering a successful product. The beauty of applying multiple levels of abstraction in our design process is that each level can address the questions, considerations and tradeoffs that need to be made at that level to allow us to move forward. By keeping each level as abstract as possible we realize a process that allows for optimal incremental refinement. Each level of decision can be made with all of the information available at that level.

With the tools and techniques we can apply today, the spirit of the delayed binding philosophy can be efficiently applied to the ESL design process to achieve more optimal systems with very flexible implementations—but only if we can resist the urge to over constrain the implementation before it needs to be constrained. Don’t let anyone tell you it’s procrastination. It is really keeping all options open as long as possible, leading to an end system implementation with the best possibility of success.

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