Your UML Tutorial- UML, XML, ESL, MATLAB & Simulink, too

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)

[Editor's Note: The figure is from the chapter 10 in UML for SoC Design, edited by Grant Martin and Wolfgang Müller, and printed here with permission from Springer. Chapter 10 was written by Yves Vanderperren and Wim Dehaene [Katholieke Universiteit Leuven] and entitled "A Model Driven Development Process for Lower Power SoC Using UML."]

“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.”

« Previous Page 1 | 2 | 3 | 4  Next Page »


Review Article Be the first to review this article
Featured Video
Peggy AycinenaWhat Would Joe Do?
by Peggy Aycinena
Job Openings: Can EDA Predict the Future
More Editorial  
Senior FPGA Designer for Fidus Electronic Product Development at Fremont, CA
Timing Design Engineer(Job Number: 17001757) for Global Foundaries at Santa Clara, CA
Engr, Elec Des 2 for KLA-Tencor at Milpitas, CA
Technical Support Engineer for EDA Careers at Freemont, CA
Technical Support Engineer Germany/UK for EDA Careers at San Jose, CA
Upcoming Events
CDNLive Silicon Valley 2017 at Santa Clara Convention Center Santa Clara CA - Apr 11 - 12, 2017
10th Anniversary of Cyber-Physical Systems Week at Pittsburgh, PA, USA PA - Apr 18 - 21, 2017
DVCon 2017 China, April 19, 2017, Parkyard Hotel Shanghai, China at Parkyard Hotel Shanghai Shanghai China - Apr 19, 2017
Zuken Innovation World 2017 at Hilton Head Marriott Resort & Spa Hilton Head Island NC - Apr 24 - 26, 2017
S2C: FPGA Base prototyping- Download white paper

Internet Business Systems © 2017 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
AECCafe - Architectural Design and Engineering TechJobsCafe - Technical Jobs and Resumes GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy