This is review of the book ESL Models and their Applications by Brian Bailey and Grant Martin. As I’m an engineer and not a story teller, I’ll take the methodical approach of analyzing the book chapter by chapter. This is the first of two installments covering chapters 1 through 5; I will get to chapters 6 through 9 in a subsequent post. I also posed a few questions to Brian and Grant where I thought it would be interesting to see them elaborate on some of the statements in the book. That Q/A can be found at the end of the review.

Initial Impression

If you find yourself leafing through the book, it will be hard to miss the fact that it is quite dense. There is a lot of material covered and a lot of detail starting right from the opening chapter. Being that I’m not a huge fan of technical details, 420 pages did (admittedly) scare me at first. For a book that has an incredible amount of detail, however, it does read relatively well. For the most part, there is a good balance between background, theory and practical experience so readers should enjoy reading a book this is one part history lesson, one part learning experience, one part tool evaluation.

Though the first five chapters, I found ESL Models and their Application to quite an informative and enlightening read. Brian and Grant are obviously experts in the field. I will say that there are places where I thought more/less detail would be more suitable or where my own approach would differ slightly… but with them being the experts, of course, take my critique with a grain of salt!

Thanks to Brian for providing me with a copy of the book.

Let’s get started!

Chapter 1 – Introduction

The opening sections of chapter 1 provided some interesting context with respect to the purpose of modeling in general, not just ESL modeling. The authors make the point that assessing accuracy and adequacy of a model is important in terms of the intended application. Complex models with accurate system representation can be overkill for some applications. Conversely, simpler approximate representations can be completely inadequate. It is important for people to understand what their application requires before they decide what type of model is most suitable.

For assessing model and application, I found the model taxonomy for ESL particularly interesting in this chapter. Using data, temporal, concurrency, communication and configuration axes, one can suitably classify models. The taxonomy also applies to modeling languages where taxonomy diagrams in figures 1.6 and 1.7 are used to describe the differences between C and SystemC and limitations of C when it comes to concurrency and communications. The 5 axes help to illustrate differences very well. Readers could easily apply the taxonomy to other modeling languages to gain valuable insight into how they differ and their suitability for certain modeling applications.

Chapter 2 – IP Meta-models for SoC Assembly and HW/SW Interfaces

Being completely honest, chapter 2 did not start out how I had hoped. Pages 33-41 contained an in depth discussion of SPIRIT/IP-XACT that was tough for me to read (I admittedly was a bit worried by the 4+ page XML example specification). That worry very quickly passed in section 2.4 with a discussion on register definition languages (RDLs).

I found this to be the most generally applicable and practical portion of the book thus far. There is a lot of insight in this section that can help hardware developers understand the goals of software developers and vice versa. Much of the material is likely to solidify what most experienced developers on either side of the interface already know but it will no doubt help them understand the reasoning behind decisions they are already be making.

For junior developers, there is some very good rule-of-thumb type guidance. One example from page 45: “best practice in embedded software design is to ensure optimal processor performance by reducing the number of transactions between hardware and software”. A second example from page 52 notes that “a self contained block with a standard notation for registers and bitfields” makes register verification easier. Both are simple bits of advice but highly applicable and easy to comprehend for junior engineers.

Further, chapter 2 discusses the characteristics of each of RAL (VMM), the ovm_register packages (OVM) and VR_AD (eRM) and the ways in which they allow for abstraction of a register interface. This is the first of many instances where currently available tools and development libraries are discussed making the book useful for people looking for a view of the current ESL tool landscape.

The chapter closes with a summary of justification for using an RDL: building code that is correct by construction and ensuring synchronization between model and RTL development to streamline software integration.

Chapter 2 was, in my opinion, the most practical and universally applicable chapter in the first half of the book.

Chapter 3 – Functional Models

After a brief history of Matlab and Simulink and a description of algorithmic modeling languages, the meat of chapter 3 includes all things related to systemC and TLM2.0. The fundamentals of SystemC were very well covered. This included discussion regarding concurrency in SystemC–at the module and process level–that nicely supported the modeling taxonomy diagrams from chapter 1. The concept of time and event synchronization were also discussed as part of a high-level but informative description of the SystemC language.

Further discussion on SystemC included applications in high-level synthesis, multi-application SoC development and multi-chip development. Discussion regarding multi-application SoC development was particular insightful where the authors point out that static analysis is not enough when assessing the interactions and implications for multi-application SoCs. From page 111, “a corollary to Murphy’s law predicts that a new scenario will come along that will invalidate all the assumptions made through static analysis…Thus further dynamic, simulation-based, analysis is needed.” I liked this statement very much because it validates much of what I have discovered regarding an empirical approach to IC development (derived from Agile software development). Feedback from a functioning system is required to make decisions that are not possible through static analysis, or big up front design (BUFD) as it is often called in Agile software development circles. (for more on Agile methods in IC development, check out www.agilesoc.com/articles)

Overall, the discussion on SystemC and TLM2.0 provides a great overview of their advantages and limitations in model development.

Two things that I would have liked to have seen in chapter 3:

• I have always found sequence diagrams, like those shown in figures 3.3 and 3.4, very effective for visualizing the difference between loosely timed (LT) and approximately timed (AT) modeling. I would have like to have seen more of these diagrams to illustrate the differences between 1, 2, and 4 phase AT communication with a discussion on where each is best applied.
• I would have liked to have seen a more elaborate discussion on temporal decoupling. The benefit of limiting context switching is noted and understandable but more details on the possible complexity–I think there can be huge complexity where temporal decoupled is used in systems with initiators–would have been quite interesting.

Chapter 4 – Testbench Models

This chapter opens with a very wise observation that in verification “…we spend most of our time verifying that we have implemented something correctly, rather than determining that we have specified the right thing.” (page 143). This is certainly a very easy problem to spot in RTL verification where verification engineers tend to become far more concerned with the details of implementation while ignoring the system level context–and more critically, the value of the model in the eyes of its customer.

Chapter 4 includes a comparison of what the authors refer to as the classic V diagram (fig 4.1) depicting traditional design process and proposed modified V diagram (fig 4.3) for a top-down approach to development.

The traditional V diagram describes what most IC developers are most familiar with: a system is decomposed into a collection of low level blocks. Those blocks are verified first. Subsequently, sub-systems are verified, then the system is verified after which the system goes through a validation process. One problem noted by the authors regarding this traditional process is that because verification first happens on the RTL, the RTL must be ready for verification to make meaningful progress (i.e. verify the product). A second problem, that I do not totally agree with, is that block-level testbenches tend to be difficult to re-use through the process of integration.

While testbench reuse can be poorly executed, I do not think poor execution is grounds for invalidating the bottom up approach of traditional verification. It is a hurdle that I have seen overcome through a combination of foresight and experience (both are necessary). I’ll admit though, that the experience usually comes from prior failed attempts at testbench reuse so while I think it is possible, it can be difficult for sure.

A larger problem that I see is that the system level perspective is completely ignored until well into the integration phase, after block level verification concludes (I believe this point is inferred in subsequent discussion but not specifically mentioned as a fault of bottom-up development). The danger is that the system level perspective is also the customer perspective. In many cases, therefore, the customer effectively has little or no insight into what they are getting until well into development–sometimes even not until engineering samples are delivered.

The authors propose a modified V diagram as an alternative to the traditional approach. The modified approach is top-down where verification begins at the system level and then filters down to the implementation. There are benefits to this approach, namely the specification is verified earlier in the process–using a model–relative to the time it takes to begin verifying implementation (RTL). The major advantage noted by the authors is that integration verification as it exists in the traditional approach is virtually eliminated because the architecture and interfacing is essentially verified before implementation even begins.

This is definitely an interesting approach. The specification is validated before the implementation and the customer perspective drives the development process. One concern I have, however, is that there is an implied waterfall progression from system validation down to verification of sub-systems, major blocks to smaller blocks. To paraphrase the corollary to Murphy’s law stated earlier, there can be situations where implementation limitations may invalidate the assumptions made during system validation, sub-system verification and so on.

While I like the modified approach, it may benefit from incremental completion of product slices where portions of the specification are validated, etc, down to verification of the implementation–or multiple modified V development cycles through to a finished product. That would enable the feedback loop from implementation ideally back to the architecture, thereby avoiding the occasional scenario where “the modeling guy doesn’t have a clue what his algorithms actually look like in hardware”.

Moving on, discussion of verification planning was a place with yet another wise observation. From page 153, “the main value in developing [the verification plan] became the thought process that led up to it, rather than the document itself”. That sounded rather similar to another famous quote by Dwight D. Eisenhower, “in preparing for battle, I have always found that plans are useless, but planning is indispensible”. Eisenhower would have made a good verification engineer!

The authors speak to the value of planning tools and how they can add value to the plan that falls out of the planning process with another practical example using VMM Planner from Synopsys. The chapter closes with a discussion on progress metrics like functional coverage.

Good chapter overall that should generate a lot of discussion.

Chapter 5 – Virtual Prototypes and Mixed Abstraction Modeling

I found this chapter to one of hope and possibility, nicely summarized in the very last paragraph where, “…the future for [system level virtual prototypes] is so wide open that predicting the future is like saying that almost everything is likely to change.” Perhaps a little foreshadowing for the 2^nd edition?

From the modified V diagram proposed in chapter 5, it is noted that one benefit of an SLVP is early validation at the system level and, “each successive refinement step can be verification against the original model” (pg 179).

Another practical example in this chapter shows SLVP development with Synopsys Innovator. The example is great for showing some of the possibilities for SLVPs. One such possibility is early development, integration and actual demonstration of a GUI-based user interfaces implemented on an SLVP. Two other possibilities are shown in section 5.6.1 where 2 USB-based SLVPs are integrated with real hardware. The first is a virtual USB device connected to a real host. The counter example is also given the platform itself is the host and connected to it is a real USB device. First, the USB SLVP examples illustrate the potential for “real world verification”, mentioned in chapter 3. Second, they show the possibilities for real world software development based on the platform.

Chapter 5 is a great section for conveying possibilities when it comes to SLVP development.

Summary

Book review or book report? Hard to say at this point… but if you made it this far, surely you will want to stay tuned for part 2 where I will cover chapters 6 through 9 and offer some closing thoughts on the book.

Question and Answer

Q. In the section about non-functional languages you mention UML. It is broadly used in software, has strong tool support, a large user community and even hardware friendly variants. You note how little it is used in the hardware domain however and you don’t expect that to change. What is the reason for that? Could it be attributed to a general lack of UML experience, a reluctance to adopt sw practices or is it that simple to pinpoint? Could it be used effectively for model development?

Grant: Many years ago during the Mead-Conway revolution to VLSI design, a text language called CIF (Caltech Intermediate Form) was invented to describe polygonal layout – something that is normally described graphically.   Steve Trimberger created a tool that combined graphics and an early version of a layout language in one – you could edit the language or the graphics and find the dual representations would be updated by working in one domain or the other (see his paper on SAM in the 1981 DAC proceedings)..

However, since then, to paraphrase Kipling, “Language is Language and Graphics are Graphics and ne’er the twain shall meet”.  UML was created as a set of graphical notations to allow software systems to be described – not as a semantically precise language for system specification.   Its richness of notations have led over the years to many attempts to extend UML (by defining profiles and enhancing the notations themselves) to allow precise system specification, generation and verification.  These have not succeeded – and I would argue that in general the attempt to add precise system semantics to UML has been an attempt to cast language semantics into a semi-graphical form.   This makes the UML a dog’s breakfast of notations, and difficult to use beyond its original descriptive intent.  Various UML notations, such as sequence diagrams (which were derived from SDL’s Message Sequence Charts) have been proven in use (witness their use you cited in chapter 3), but again, much more for descriptive purposes than for precise system design.

I think the fact that it is derived from the software world and that software people don’t pay much for tools, plus the fact that IBM has bought up most of the commercial UML tools means that there has been a lack of commercially useful tools especially in ESL HW-SW system design – as well as the geographic focus which has kept UML for system design a European concept with one offshoot in Japan as a front end for SystemC – but not one that is used much.

Finally, the relative ease of creating UML profiles has led to far too many of them – SysML and MARTE for embedded systems being just two of the most recent ones – and as a result, there is no widespread community around which users, tool vendors and academia have coalesced to make UML really useful.

But I believe the fact that much of design and verification is best specified in imperative languages and not graphics, as discussed first, is the real reason why UML will not become more important in systems design.

Q: You make the following statement in section 2.4 regarding commercial viability of home-grown RDLs: “… many attempts to commercialize tools developed inside individual companies or university research projects…usually failed to be commercially viable”. What is responsible for these failures? Is there anything developers should be learning from these failures?

Brian: Quite often technology has nothing to do with success. Just think Betamax and VHS, or the latest wars in the DVD formats. It is one part technology and 10 parts marketing and or driving of standards. An RDL is similar. You could define the greatest format, but if it is only one company using it, then it has limited utility, especially if you are bringing in IP from several external sources, or if you are an IP vendor, then it may mean added time or expense to create a view of the interface that nobody else can use. Individual companies or Universities do not have the reach to make something like this a standard in most cases. They need industry support and that may mean working with your competitors, or trying to get tool vendors, who you may not buy from, to co-operate.

Grant: Even standards efforts like SPIRIT/IP-XACT and its RDL may not succeed if the demand is not there for the results.    Use of SPIRIT and RDL in the commercial world and between IP vendors and users is still not a standard deliverable and is not demanded by developers – because often they add little to the real design and integration process.

Q. SoC solutions, by definition, exist partly in the software domain and partly in the hardware domain. In chapter 4, it finally became apparent to me that there is remarkable flexibility when it comes to drawing the partition between hardware and software. How do you see the relationships between hardware, software and modeling experts evolving to properly take advantage of this flexibility?

Brian: Maybe some of these questions will be answered when you get to chapter 6 which focused on this very question.  (Grant: I totally agree) I also believe that I time we will begin to see more generic platforms composed a processors, standard peripherals and a certain amount of reconfigurable logic that can be used to put hardware accelerators. In fact this is exactly what that 5^th axis in the taxonomy is all about – the configurability axis. Today we tend to see FPGAs as being reconfigured at system startup, or possibly just a few times during product operation. But what if they started to be dynamically reconfigured and we actually did synthesis on the fly for pieces of software that needed to be accelerated. In simulation tools we already see a lot of just-in-time compilation to speed up execution. How long before we work out how to do similar things for the application domain?  Maybe even one of the processors on the chip deciding what needs to be accelerated and doing the synthesis – right there on the chip. This would make for a whole new business model for EDA.

Q. In the discussion regarding Synopsys Innovator in chapter 5, you mention that Innovator uses the eclipse framework “allowing user written Java plug-ins to enhance the debug capabilities”. Do you see esl/hardware experts taking advantage of these possibilities that a framework like eclipse offers now and into the future?

Brian: A transition such as this may take time, but the fact that EDA tool development has started to use standard frameworks such as Eclipse will enable a lot more innovation in the future, and in particular those that would benefit specific vertical industries or flows. For example, there may be certain views of a system that may be more applicable to the automotive industry, and thus it could be possible for an auto company to develop these in-house, or for a startup to provide a specific add on package targeted at this industry. Given that the development that they have to do is small (they do not have to replicate all of the functionality provided by the core package) it becomes cost effective to just design and sell small add-on packages. Think of the success that this has created in the photographic processing industry. At the center is Adobe Photoshop and there are hundreds of add-ons that you can buy for creating specific effects, or doing certain transformations, or even for improving on some of the capabilities of the core program. Similar success also exists in the 2D and 3D design space based on AutoCAD. This can only bode well for the EDA industry and customers alike.