Warning: Undefined array key "upload_with_nude_flag" in /www/www_com/htdocs/get_weekly_feature_ad.inc.php on line 69
Raise your hand if you know what UML is, why it is (or isn't) important to electronic design automation, and what its implications are within the context of ESL in EDA. And also, while you're at it, raise your hand if you know how UML relates to XML, and whether either of these representations have a role to play in chip design.
Then, take this pop quiz. Each answer is worth 1 point.
- What does UML stand for?
- What does XML stand for?
- What does ESL stand for?
- What does OMG stand for?
- What does SPIRIT stand for?
- What does MATLAB stand for?
- What does XMI stand for?
- What does SysML stand for?
- What does Simulink stand for?
- Where is DAC 2006?
5-8 points - get yourself to the UML Tutorial at DAC on July 23rd.
0-4 points - get a job in a different industry!
May 15, 2006
Hello Peggy,
I'm contacting you after reading a sentence in your article about DATE 2006: "Ian Oliver [from Nokia] said there are as many UMLs as there are applications, but no standards and nothing in the UML world fits together".
There is truth in this statement, but the situation is obviously more complex and less negative as it might look like with such a short sentence. The UML-SoC workshop at DAC provides an opportunity to better understand the situation.
The workshop is a place where design teams and researchers from around the world present their work exploring the application of UML for complex chip design. It takes place on the Sunday before DAC and was initiated by Grant Martin and Wolfgang Müller in 2004.
This year will be the third edition and is organized by John Wolfe, from Mentor Graphics, and myself. I have attached the detailed program (which is also available on www.dac.com and www.c-lab.de/uml-soc), a short summary of the workshop, and an interesting article on UML and SoC design from the organizers of last year's workshop (Wolfgang Müller and Luciano Lavagno).
This year we have introduced a special coffee break during which several presenters will show tool demos and more concrete details about their work. As organizers of the workshop, we believe it is indeed very important to encourage close interaction between the presenters and the audience, and give the opportunity to see examples of UML-based SoC design and how UML is used and supported in practice:
* NEC will present their work on NoCs,
* STMicroelectronics will present the way they associate UML and SystemC,
* ArtisanSW will present their SystemC code generator and how they implemented the UML-SoC profile (the extension to UML for SoC design which will be discussed during the keynote of the workshop) for a project which ran at Philips in the U.K.
As you can see from this list, there is a growing interest from the industry for UML and its application to complex chip design.
As the workshop is meant as a place for interaction and knowledge exchange, we have also introduced at the end of the workshop a special session with an open discussion about the current situation of UML-based SoC design. Any participant to the workshop can contribute to the discussion, which will be moderated by John and myself. We believe the program of the workshop is attractive, and constitutes this year a good complement to the Monday tutorial on ESL design methodology using SystemC.
Coming back to the statement of Ian Oliver-Wolfgang Müller and I gave at DATE 2006 a tutorial about UML and SoC design which was quite successful, more than 50 people attended, and it was ranked #2 in terms of tutorial audience. We tried to give a clear and objective overview of the situation, and that is the same direction John Wolfe and I aim for in the upcoming DAC workshop.
Best Regards,
John Wolfe & Yves Vanderperren
UML-SOC'06 Organizers
Sunday Workshop 43rd DAC
After receiving this e-mail, I had a chance to speak by conference call with John Wolfe and Yves Vanderperren. John was in Arizona, where he is Director of Operations and Engineering for the Mentor Graphics' Embedded Systems division, and Yves was in Belgium, where he is on the EE faculty at Katholieke Universiteit Leuven.
I asked John and Yves to start by distinguishing between UML, XML, and ESL.
From his office in Leuven, Yves told me that UML comes from the software design world, and is a visual language for specifying, constructing, and documenting the artifacts of systems: "The Unified Modeling Language provides a means for the graphical representation of the structure and the behavior of systems. UML is not a methodology or a way of designing systems - usually called a 'Development Process' in the UML context - but provides support for communication within a development process."
"XML, the eXtensible Markup Language, is basically a text-based description for many different types of information. It allows the creation of customized tags, enabling the definition, transmission, validation, and interpretation of data between tools. It is at a lower level of sophistication than UML. For instance, XMI, the XML Metadata Interchange, is an XML-based specification for the file format and exchange of UML models. As another example, the SPIRIT 1.0 specification provides a standard XML data format for IP integration data."
Yves said, "Regarding ESL, I would say that UML is a member of the ESL family. There are many languages in the ESL family, including C++, SystemC, SpecC, and the C-based language from Mentor. There's also MATLAB, and multiple verification languages. UML is a language on its own, but it can be associated with other design and implementation languages."
"One way to look at UML is as a complement to the C/C++-based languages, because those languages are pure code with no way to represent systems in a graphical way. UML provides a standard graphical way to represent the code."
Based on that comment, I asked Yves if UML is really a language, or is just a standardized set of picture grams, formalisms for drawing on white boards? And if that's true, why does it take 9 hours at DAC to hash through the whole thing?
Yves said, "UML can be now considered as a language since the basic behavior of a system can be described with 'Actions' - in other words, the fundamental units of UML behavior with a defined semantics. This allows an executable application to be generated from a UML model.”
“However, the syntax of these actions is not defined in the UML specification, and any tool-specific action language or other languages such as C++ could be used. However, as well, a major point of discussion with UML is that it intentionally leaves several details open.”
“Although UML standardizes the syntax of the diagrams, it does not provide the detailed semantics of the implementation of their functionality and structure. The domains in which UML can be applied are indeed so different that they cannot be unified under a single semantics. UML, therefore, remains a semi-formal language and allows semantic variation points - in other words, the interpretation of a UML model may vary according to the application area.”
“The specification of domain-specific interpretations of UML is done via what is called a 'UML Profile.' Several people have worked on the customization of UML towards semiconductor design, providing different kinds of answers - different profiles - having various scopes, and pros and cons. It is in this context that the comment from Ian Oliver at DATE about different UMLs can be fully understood. Finally, as for any language, there is also room for discussion about how to use UML and these extensions for SoC design.”
Yves listed several examples: “For example, executable models of a system using C++-based languages such as SystemC allow for the complete validating of a system's behavior because they avoid the ambiguity of static paper specifications. These models also capture essential characteristics of the system such that its performance can be quantified early.”
“Last, but not least, an executable model can act as a reference for test generation and input to the detailed design. However, these models are typically based on pure code and provide no way to represent ideas in a graphical way. UML provides a standard way to represent systems that can be understood by system architects, software and hardware engineers.”
I told Yves it was my impression that some people are using MATLAB [from The MathWorks] to facilitate these conversations between system architects and software/hardware engineers these days.
Yves said, “Several recent EDA surveys confirm that MATLAB/Simulink [together] and UML are both gaining increased attention as ESL languages. However since 2002, I have indeed seen people increasingly using UML to develop embedded systems. MATLAB is actually a complement to UML with a focus on signal processing and algorithmic design. Tools which associate UML and MATLAB exist, and support integrated design flows which exploit the benefits of this complementarity."
"In addition, SysML [Systems Modeling Language] which extends UML for general systems engineering, proposes several concepts close to what is available in Simulink. A key strength of UML is that it has the potential to support innovative methodologies, which tie the architecture, design, and verification aspects in a unified perspective. The broad scope of UML allows structuring of the thinking and action on a design, to support a process that improves the overall product quality as well as the project predictability. But UML leaves freedom of choice and doesn't force any of these processes.”
He added, “The introduction of UML is an opportunity to make some changes and get closer to iterative development processes. Traditionally, design follows a waterfall process with people waiting for each other to complete their tasks. Architectural design makes a split between hardware and software, and then when the hardware design is complete, the software is mounted on the hardware to verify the entire system. Using UML does not preclude this process, which is a practical one, but encourages a different point of view.” (see Figure)
|
“Large scale systems can instead be constructed incrementally as a series of smaller deliverables of increasing completeness which are evaluated in order to produce inputs to the next iteration. Each iteration involves several disciplines of system development running in parallel with variable effort. Using UML, you gradually improve coverage of your executable model and the knowledge of the system you're designing. This continuous feedback loop and early testing improves the quality of the final product.”
John Wolfe, from his office in Phoenix, added, “On the methodology front, it's a different issue. UML is a standardized way of drawing a particular set of symbols, although the semantics have not been completely standardized. There is a movement underway inside of the OMG - the Object Management Group [a consortium that standardizes UML and its extensions] - to standardize on a framework, however, and that will continue to bring more rigor into the work. However, UML is still, by no means a methodology. It is a family of languages with which you can construct anything from a sketch of the code you intend to hand-craft to a fully executable model of a system."
John referenced the DATE panel again: “If you look at the statement you quote from Ian Oliver, the situation with regards to UML is not quite as negative as you might think from his single sentence. UML is really a family of languages, which provides an ability to extend design. But there has been a separate UML language for each application that's come along. So, one of the difficulties in trying to understand the UML space has been to distinguish between the languages.”
“Not surprisingly, we see confusion in the market and in the way the languages have been provided. There is work being done, however, to encourage convergence. For UML to be useful for design, particularly within EDA, there has to be some standardization. When that happens, and when people begin to understand the standard, there will be progress.”
John said the situation is more easily understood when described in terms of the better-known languages: “If I hire a C programmer off the street, or an RTL designer off the street, and then teach that person about cell phones, or communications protocols, or about the intricacies of wireless systems, or cardiac rhythm management systems, the basic knowledge of how to express a design and an implementation, is [actually] common across those areas. And, that is only possible when you have standards in the industry. Without a standard [in UML], we find one person with 'UML' on their resume has a completely different understanding of the language from someone else that also has 'UML' on their resume.”
“Plus,” John said, “We're missing the network effect without standardization. The design tools are not interchangeable and can't be separated from different vendors from different parts of the lifecycle. When there's a standard, you can choose one tool to define the design, a different one to refine the design, a different tool for implementation, and a different tool to document. That's a very small part of the equation for the EDA industry. ”
Yves said from Leuven, “In 2002, several people started applying UML to a global system of chip design. As a result, a profile is currently under standardization at the OMG which will include specific extensions for chip design meant to be independent of languages. I was working at STMicro, and those people have continued the efforts we initiated there around UML and SystemC, and how to represent SystemC constructs in UML. They have developed a specific UML/SystemC profile. We expect to see a convergence between the different efforts which try bringing UML and SoC design closer, and the UML workshop at DAC provides an opportunity to better understand these works.”
Yves reiterated the relevance of UML to EDA: “Back to the point of the EDA tools - at the workshop, you will see several demonstrations. There will be tools from NEC, as well as from ArtisanSW, Philips, and STMicro, plus there will be ample room for interaction between the presenters and the people attending the workshop. People will be able to see more concretely how UML is being used for design.”
I asked Yves if there is more interest, in general, in Europe in UML. He said, “I would not say there is more interest in Europe. If you look at the number of submissions we received - we saw several from North and South America, and Asia, as well as from Europe. There is a strong movement in Japan towards using UML, and of course, in Europe the work is quite advanced. At DAC, we will provide a way to bring all of these different groups together. The important thing is that it not only be conceptual, but [practical] as well.”
“Besides the graphical representation of code using UML, there is the effort to go from a higher to a lower level of implementation. Although there is increasing tool support in the direction from UML to the SoC languages, there is currently still no mechanism to represent the path from the models to the implementation. While conceptually UML models can be transformed and go from one form of the model to another, it will still be in the same way that a person writing in an HDL is using a synthesis tool to make the transition from a [higher level of abstraction] and must have a clear understanding of what will be the synthesis results depending on the quality of the HDL code.”
John added from Phoenix, “I think we can draw a couple of analogies on the software side of the world. Using C for embedded systems to design operating systems, or drivers, has been the better way to do things for over 20 years now. But [even today] some pieces of an embedded system are written in Assembly language.”
“On the hardware side of the world, it's been two decades now with the HDLs in place, but some people are still designing logic with gates. There will never come a time when UML completely replaces the HDLs, but UML will find its primary home where complexity drives the adoption of new techniques.”
“That's the primary reason that we saw higher levels of abstraction and newer approaches to designing hardware and software. There came a point where it was just too difficult to build systems in lower-level languages. So we moved to higher-level languages for [ease of] expression. Then, we built tools around those languages. In the industry now, there are two parallel paths for managing complexity. One is to raise the level of abstraction, yet again. The other is simply to improve the tools around the existing languages. It's not yet clear to me which one of these two approaches will win, maybe both will win.”
I suggested at this point in our conversation that if SystemC is a version of C constrained to meet the design needs of the users, is there a constrained version of UML that would meet similar needs?
John answered, “We can expect to see a continued proliferation of languages. Some of the profiles are simply tracking existing version of the languages up through graphics and UML implementations. Other approaches involve constraining and making extensions that attempt to provide that higher level of abstraction. Which of these will become dominant or prevalent, it's just too early to tell right now. But certainly, you will see some of what you have already recognized in SystemC - a constraining for the sake of hardware design and also some tailoring of the language for that purpose. I use the word 'tailor' as a combination of constraints and extensions, not just one or the other.”
So then, why not combine the ESL and UML tutorials at DAC?
Yves said, “I think definitely that would help. When we gave our UML tutorial at DATE in Munich, we tried to offer an overview and show how it also combines with other languages and design flows. Yes, going forward, the ESL and UML tutorials may be combined. But right now, most of STMicro's work, for instance, is being done by an advanced team from their research department, so it's still only being looked at from a research perspective.”
John added, “I think maybe one of the reasons the two tutorials haven't been combined yet is because the two movements have been proceeding in parallel. As Yves points out, UML and applications of UML to designing hardware has only been a piece of the overall ESL movement."
"If we look at that movement today, it's one of those things that's not yet fully defined by the industry. There's a demand from many of Mentor's customers for some sort of system-level approach for design and implementation of systems. And, by systems, I mean things that include microprocessors, some custom logic, and some custom software. This is where we're seeing the demand for ESL tools.”
“Currently, there are a number of different approaches and tools jockeying for position in this new landscape. UML and its application to system design are part of that - although it's probably a bit early to combine all of the different approaches into one language or a single forum. At this point, ESL needs to be understood from the perspective of the tool vendors and users. At this point, the vendor's need to understand what their customers want, and UML is only one piece in that possible flow.”
“Just to give you an idea of the spectrum. UML could be used for visualizing the big picture of your system, and then pushing it forward to use all of the various design and implementation techniques available today. And on the other end of the spectrum, you could use UML to model whole systems in a very unambiguous way, and you could synthesize directly from those models into an implementation. UML can be at those two ends of the spectrum. Today, ESL is only focusing on the system-level picture, not at the implementation level.”
Yves added, “As you mentioned, UML does not force a methodology. You can act from the beginning and structure the requirements in UML, or SysML, to get an understanding of a system and what it should eventually do. You can also examine 'Use Cases' - in other words, sunny-day and rainy-day scenarios of how the system should react. And then, people can decide which implementation language to use at that point and how to associate it with UML. Really, with UML there is complete freedom. At the workshop, people will discuss the advantages and disadvantages of the different possibilities."
I asked John and Yves who should, or would, be attending their workshop on July 23rd in San Francisco.
John said, “Primarily, people who are in the implementation companies will attend. We have not seen much participation from the tool vendors as yet, but that could change this year. The tool vendors are definitely taking an interest in the ESL space, but not necessarily taking it ahead a step to show interest in the UML space. At some point, however, we will begin to see a merging of the two movements. We will see a time when UML can be used for the design of a single logic block, or a group of chips. It's already being used by the industry in a big way for software design.”
“Having said that, I don't think UML is critical to ESL or vice versa. They're still relatively independent and may remain that way for quite a while.
Yves added a final note, “On top of considerations of designing hardware or just software with UML, there is the issue of having full support from the users. Up to now, you can find good experts coming from the software point of view. But, it's more difficult without tool support on the hardware side to see people with that type of background coming to understand what UML can offer. Trying to bring all of these people together in one place is one of our motivations for this workshop.”
“It will not really be a tutorial, but more of a forum. There will be tool demonstrations, so people can see concrete uses of UML from NEC, Philips, Fujitsu, and so on, as well as presentations and many opportunities to ask questions. At the end of the day, John and I will moderate a discussion that will bring to the table all of the various points of view that will have been expressed over the course of the day.”
John Wolfe and Yves Vanderperren will be co-chairing the tutorial on UML at DAC on July 23rd in San Francisco. It's going to be very interesting at many levels. You need to carve out some time to attend.
Addendum
To help clarify a few things, I had a chance to speak by phone with Jim Tung, Fellow at The MathWorks, and Ken Karnofsky, Marketing Director at The MathWorks, following my conversation with John Wolfe and Yves Venderperren. This is a brief synopsis of our conversation, and all the more reason for you to be attending the UML Tutorial at DAC:
Q - UML & The MathWorks?
Jim - It's true that when you look at our products versus the entire definition of UML, there is some overlap.
But UML attempts to be many things. Today, there are over a dozen different diagrams that comprise UML 2. Some are useful and frequently used, but others are not used very often, but they are there for completeness. When we talk to the users and tool vendors, the usage falls into a couple of different categories. Most frequently, UML is used as a drawing tool to identify what the pieces of the system are, and what the interactions are, essentially for high-level analysis. The use-case diagrams in UML are frequently used, because that's something that system analysts understand.
Less often, but still pretty common, is the use of certain diagrams for architecting software - particularly using object-oriented approaches. Some diagrams in UML are useful for describing how the software application would break down into components. However, UML is not as appropriate for saying what functionality those components should perform, or how that functionality should be implemented - but it is very good at describing the software architecture.
When I think about any perceived overlap between UML and our products, it's due to what is in the UML definition, not the use of the tools. In practice, many users have a good sense of what each tool is well suited to, and they continue to refine that understanding. We know that UML is well suited for some tasks. We sometimes use UML tools in-house for some architecture work in our own product development.
Whose UML tools do we use? We would prefer not to say which ones, but we use several. We prefer to stay agnostic and maintain relationships with a number [of different UML vendors].
Q - ESL & The MathWorks?
Ken - Well, there's a similar situation in the ESL realm, because ESL means different things to different people. But, the concept of ESL is coming from the electronic design world and recognizes that ICs are getting more complex and more software-centric than ever before. The largest source of error in those systems - and the reason why so much money is being spent on reducing those errors - is that the up-front specifications are incorrect. Therefore, there are a growing number of tools in the ESL space, but they address a range of sub-problems within electronic system design.
Most ESL tools today are internally developed by customers and are used to define virtual platforms that describe SoC architectures, including elements like buses, processors, and so forth. How do you model such a device adequately? Some of these customers use MATLAB and Simulink to describe the functional behavior of that system, and what the system or component will do. Then we provide a route to implementation with automatic code generation as well as links to the downstream tools. For hardware, we have a path to implementation through our partnerships with the FPGA vendors. And, there is some capability for direct HDL generation for digital filters.
ESL is addressing the definition of SoC platforms that include programmable devices such as microprocessors and DSP cores. Model-based design with Simulink also encompasses other components that make up the complete end product as well as its environmental effects on system performance. MATLAB provides a higher level of abstraction and productivity than the current ESL languages for algorithm development.
To some extent, our products have always been addressing problems that are now being recognized by the EDA industry and reflected in the ESL market definition. At the same time, we have extended our products from simulation and algorithm development to implementation. It happened first on the embedded software side, starting 10 years ago, and now the connection to the EDA side is happening for both implementation and verification. For example, our Link for ModelSim product provides a way for people in the hardware domain to use Simulink models as a kind of a testbench.
Q - MATLAB versus Simulink?
Ken - People need to distinguish between MATLAB and Simulink.
Jim - MATLAB deals with algorithms, while Simulink deals with various aspects of system complexity. Simulink can be used for hardware, software, analog, digital, or mechanical systems. If you have a block within the system that is an algorithm, you can purchase IP blocks from us, or build blocks out of lower-level blocks, or create new blocks written with MATLAB or a C wrapper. We're open in terms of how the components are created.
As Ken says, you can describe both hardware and software using Simulink. More importantly, you can describe the algorithmic behavior of the components of a system using MATLAB, and then you can implement it down to the production level through automatic code generation. So, we have these relationships with Xilinx and Altera for implementation of such flows into FPGAs.
Ken - Simulink is being used by development teams for model-based design, both hardware and software. Those systems can even include mechanical or hydraulic systems. Starting with models in Simulink allows the specification to be unambiguous and testable from the start. Then they can be refined as the algorithm is developed, whether in MATLAB or Simulink.
People tend to recognize MATLAB more than Simulink, because a lot of people have used MATLAB for certain aspects of system design. In fact, we have many documented cases showing that MATLAB is more efficient for writing algorithms than C or C-based languages.
Q - Was The MathWorks at DAC last year in an educational mode?
Ken - We were not at DAC last year in a tutorial mode. We were invited to participate in a panel discussion.
Jim - [In fact], The MathWorks was at DAC last year, because the panel discussion was motivated by the users. It was recognition from the marketplace that our tools are being used. It was far more than just our being in an evangelical mode.
Q - The concept of a UML tutorial at DAC?
Jim - Since there is a gap between the definition and practical use of UML, a UML tutorial would be useful if it involves users showing other users what it's good at - if it is presented from the user perspective, not a tool vendor or evangelist perspective. There definitely needs to be an acknowledgement of what things UML is well suited for, and what things other tools are well suited for.
****************************
Editor's Note - Here are the answers to your pop quiz:
- Unified Modeling Language
- eXtensible Markup Language
- Electronic System Level
- Object Management Group
- Structure for Packaging, Integrating and Re-using IP within Tool-flows
- Matrix Laboratory
- XML Metadata Interchange
- Systems Modeling Language
- Simulink is not an acronym. It's the name of its purpose: simulation.
- San Francisco, July 23rd to 28th (!)
You can find the full EDACafe.com event calendar here.
To read more news, click here.
-- Peggy Aycinena, EDACafe.com Contributing Editor.