Model-Based Engineering for Complex Electronic Systems

Mantooth

Section 1. Fundamentals for Model-Based Engineering

The first section of the book describes the key fundamentals for successfully accomplishing model based engineering (MBE). The first chapter introduces the topic of MBE, the alternative approaches to MBE, and what this book will teach the reader. The idea is to engage engineers from the very beginning with specific real-world examples of design, talking about how modeling is crucial to the processes involved and talking about solving real problems. We extend the scope of models from just a piece of code into all the facets of a rich entity that has a symbol, structure, equations, behavior, test circuits and validity regions, and executable specifications. Chapter 1 highlights the fact that engineers do these things already.

Chapter 2 talks about design and verification process and Chapter 3 provides a rapid tutorial on computer simulation methods typically used for analog, digital and mixed-signal electronics. These chapters are very important for understanding the context of design analysis. In deference to the late, well-known designer, Bob Pease, who was fond of giving simulators the business, simulation is indeed a very useful tool, but cannot replace the brain. The designer must perform the design activity and use simulation as an extra tool to evaluate the design among the other tools at his disposal such as breadboarding. The biggest value in simulation is being able to quickly analyze many scenarios of electronic systems. However, it needs the guidance of the designer to design the circuitry and the approach to verifying them. Further, simulation can be used in an optimization or statistical context to evaluate many variations. And finally, simulation can be extremely valuable in troubleshooting a design when guided by the designer’s insights. The major advantage of a simulation is the ability to look inside components within a design to enhance the designer’s understanding of the behavior of that design.

Chapter 4 concludes the first section by laying down the fundamentals of modeling, modeling techniques, and describing tools and forms of model representation which will all be described in much more detail in the chapters of Section 2.

Chapter 1

Overview of Model-Based Engineering

1.1 Introduction

This book is intended to provide designers with an insight into effective model-based engineering (MBE). The concept behind model-based engineering is to use modeling as not merely a mechanism to perform computer simulations, but to capture specifications, clarify design intent, facilitate hierarchical designs, and be efficient at collaboration, design reuse, and verification – in other words, manage complexity. This book is aimed at engineers managing or working in design teams, including those that cross engineering disciplines, such as integrated circuits, power systems, transportation systems, medical electronics, and industrial electronics to name but a few. The unifying theme that this book brings to all of these fields is being able to create and use models effectively in the design process of complex systems.

In this initial chapter, the fundamental concepts of managing complex and hierarchical designs will be introduced with a view toward providing solutions and methods to solve these issues in the remainder of this book. This book has several learning objectives as follows:

• Create a common ground for the development of MBE by:

• Summarizing for the reader the very basics of modeling and simulation

• Describing the ways in which circuits and systems can be represented

• Cover the breadth of modeling techniques and methods, including some emerging methods, while demonstrating a common creation paradigm that promotes reuse and the capture of hardware behavior appropriate to the tasks at hand

• Illustrate concepts through lots of examples, which will be available online

• Describe the keys to adoption of these methods.

To begin to motivate why MBE is important, it is instructive to understand what problems engineers are facing most prevalently. A big problem for engineers in today’s world is attempting to close the so-called Design Gap.

We can see from Figure 1.1 that the complexity of design (in this case integrated circuits) is outstripping the ability of engineers to design these more complex chips in the same time. As a result, it is taking longer in real terms to design these more complex systems. This issue of complexity is a fundamental problem for modern systems designers, whether on a chip or a large industrial project, and yet we have much more computing power available to work on these problems. Clearly, the key to success is to be able to leverage our increased computing capability and use computer-aided design (CAD) tools to manage complexity and develop systems more efficiently.

Figure 1.1 The Design Gap between the increasing complexity of electronic designs and the designer’s ability, on average, to produce them

One critical aspect of designing complex systems is developing models of parts of the system that enable design and analysis to proceed at an efficient pace. Modeling has become an integral part of almost every aspect of modern design, but not necessarily in the same or unified form. Some models are created for Matlab, others are created in spreadsheets, and still others are created in modeling languages. And yet, the number of modeling experts in each field is still relatively small, especially in the areas of mixed-signal and mixed-technology design. One reason for the development of modeling automation or productivity tools is to compensate for this lack of expertise, and provide access to the utility of hardware description language (HDL) technology without the need to become an expert programmer. This is analogous to the development of synthesis for digital systems, where, prior to the existence of automatic logic synthesis software, the synthesis process was an expert process, time-consuming and complex. When the first logic synthesis programs became generally available, the increase in productivity was huge. Being able to synthesize models from abstract descriptions is the equivalent for modeling to that of logic synthesis. This is now a capability that can be found in commercially available tools.

Moving the emphasis of the designer away from the details of the modeling language also has a profound effect on the way that design is undertaken. Currently, the approach is most akin to a software programming style, using text editors and then simulating to check for syntax errors and other bugs – much in the way that the compilation process is used in software. Moving to a design-based approach will have the effect of the designer being able to think about algorithms and behavior, transferring the thought process firmly back into the design domain rather than a programmer’s domain. This approach itself opens up the modeling field to many more non-experts than those fortunate enough to be skilled in the syntax of one or more HDL. It also increases the productivity of the designer, even though at first glance it may appear to be another task on the heap. On the contrary, with the proper modeling tools and libraries, the modeling and documentation activity already performed by most designers is converted into a more singular approach that leverages this work and begins to close the design gap.

1.2 Multiple Facets of Modeling

We can think of a model as a rich object that has many facets (Figure 1.2). The conventional approach of disconnecting the implementation of a model from its specification, test-bench, and documentation is perhaps counterproductive. In contrast, we consider a model as not just the encapsulation of the behavior in a piece of HDL or code, but rather the linked set of meta data that fully describes the design in its entirety. This meta data includes documentation, test results, design context and intent, background links and references, equations, and structure. This broader view of a model will begin to merge the distinctions between model and design in a positive way, so that members of a design team are able to gain a more complete understanding of the design – both during the initial design activity and later when the design is either being enhanced or ported to a new process. The detail and data that can be obtained from simulations serve to further enhance the richness of a model. These can include specific measurements, assertions (errors or warnings familiar to digital designers), and results from advanced analyses, such as stress or sensitivity analysis.

Figure 1.2 The model is a multi-faceted object–not just code

The activities that the designer normally engages in include pre-design documentation involving requirements, functional specification synthesis, capture, refinement, and negotiation. This design documentation can be made executable with current modeling tool technology, where a combination of test benches, waveform measures, specifications, and simple models for the device being designed are captured in a single tool rather than by multiple tools and documentation methods. This has the advantage of improved productivity for the same tasks, but offers an even greater enhancement still when you consider how these specifications are directly traceable through the CAD tools from concept to realization rather than entries into a Microsoft Word document that is disconnected from the design flow.

One cannot forget that design activity is not complete until the product is firmly in manufacturing. The initial system builds are rarely defect-free. So, the design team is often re-analyzing, discussing, and debugging any remaining issues before the design is released for large-scale manufacturing. This scenario as depicted is an optimistic one considering that, in many instances, multiple design iterations are required to produce manufacture-ready results. Therefore, the design team is engaged in debugging activities to a significant degree. Given these circumstances, MBE techniques prove to provide a substantial advantage. Consider a design where all specifications are not executable, each block of the design was designed independently, and the system designer pulled it all together to create the system. The individual blocks were designed by individuals, each with their own style and notions of what rigorous design means. Even with a talented team, this will lead to issues when the debugging rounds occur. With no unified modeling, test bench, and specification methodology in place the debugging activity will proceed longer than necessary. Figure 1.3 shows where time is spent during these multiple design iterations and how MBE methods can not only save time in the first iteration, but significantly decrease design debugging activity because the framework for simulation-based investigation of problems is already in place. While Figure 1.3 cannot illustrate a specific improvement in the general case, the thesis is that, starting with the initial design round, specification capture in companion with test bench definition takes no more time with a MBE approach than with traditional methods. And yet the big benefit is realized in the second and subsequent design rounds, which are focused on debugging and performance improvement/refinement. Figure 1.3 illustrates the relative improvement in time as compared to a situation where the system and its constitutive components are not modeled according to the MBE approach. The MBE approach establishes a framework so that, from the top system specifications down to the specifications of individual blocks, the design can quickly be analyzed at the level of detail required. This allows much more in-depth investigation of the issues, as well as much faster investigations. Among the benefits of this approach are: (a) reduced design cycle times, (b) shorter investigations to determine and address problems, and (c) reduced number of design cycles because of the improved framework for design analysis and verification (not illustrated in Figure 1.3, but very important).

Figure 1.3 Figure showing the design time comparison between those employing MBE-based methods and those not. Notice the relative improvement during the debugging rounds (iterations beyond the first)

Figure 1.3 focuses on a new design beginning from scratch, such as the first Bluetooth chipset, for example. In contrast, in our years of teaching circuit and system design we have consistently tried to set the expectations of our students that most design is re-design. By this we mean that designing a completely new function, chip, or system that the organization has no history of designing before is much more rare than the design of circuits and systems that are being improved over previous designs, or are being undertaken for a new customer but will be based on existing designs. When a design team is performing a re-design, the benefits of MBE are naturally going to be somewhat different. The use of MBE will expedite reuse and decrease the learning curve of the new engineers engaging in the re-design activity. However, whether MBE is used or not the likelihood of design re-spins is lower going into a re-design project as compared to a project with substantially new design content. However, in spite of this, the deployment of MBE methods remains a good investment for the following reasons:

1. Designs always seem to have a longer lifetime than we ever imagine. During the lifetime of a product/design, the original design team’s composition will change. New engineers will come onto the project, and others will leave it. The transfer of knowledge and the learning curve for the design is much more self-directed and efficient with the MBE approach. All of the particulars are documented, executable, and repeatable.

2. In addition to assisting the design team, the test and evaluation team is a beneficiary of the design team using MBE methods. The MBE approach actually enables the test team’s preparations and activity at an earlier stage of the design cycle, thus shortening the overall design cycle again. This is because instead of design data being thrown over the wall at the test team once the design goes to manufacturing, the test group is able to access the same design databases once designs are frozen in order to begin developing test strategies, Automatic Test Equipment (ATE) test code, and test fixturing. This effectively moves this activity up in time, thus shortening the design cycle.

3. Product support is enhanced through the use of MBE methods for the downstream engineering teams in a production environment. The application and support engineering teams are better able to support designs and handle customer requests and issues if they have a better view into the design. The MBE approach creates that view into the design that is far more conducive for investigation, troubleshooting, and learning-much as for the new project engineer referred to in (1) above.

The motivation therefore is to have a framework to create and develop models from a design perspective, which implies abstracting the behavior of individual elements and systems into a form that a designer can understand and is comfortable interacting with. The remainder of this portion of the chapter will review some of the general design issues in more detail and introduce the key requirements for MBE as a technique.

1.3 Hierarchical Design

The reality of modern design is that it is generally not feasible to design a circuit or system without using some kind of hierarchy. If we consider a typical integrated circuit in today’s world of sensors, mobile electronics, and networks, shown in Figure 1.4, we can see that multiple technologies are often required with numerous design techniques – often spread across an entire design team.

Figure 1.4 Complex design illustrating the multiple design techniques and technologies

Different blocks require design techniques appropriate for their discipline. For example, the motor driver clearly requires a different set of tools and methods than those for processor design. In most cases, the design team will consist of a number of engineers who are specialists in their own field that will work together as a team to complete the design. From a management perspective, the only way to handle this practically is to use hierarchy to implement the design and partition intelligently to assign the individual blocks appropriately.

In this context, where systems are generally mixed-signal (analog and digital content) and often mixed-technology (some interface to the real world – such as thermal, mechanical, or magnetic), the partitioning can often be intelligently made on the boundaries, such as those given in Figure 1.4. A high-density digital section of the design, such as a processor, would be best undertaken by a digital designer using digital simulation tools. Conversely, a section of analog circuitry, such as a voltage reference, is best undertaken by an analog designer with analog tools. This is fine as far as it goes, but it has often been noted that problems migrate to the boundaries in such complex designs, and it is therefore critical that the mixed signal and mixed technology aspects of the design are handled in a similar smart fashion. The other aspect of partitioning that is often neglected is the hierarchy issue. The system designer or project leader may have a completely different view of the overall design than the individual designers, with different requirements and specifications to meet. It is therefore essential, that, if at all possible, the hierarchy is managed in such a way that they can observe the overall system structure and behavior, as well as the individual blocks of the design itself (Figure