ROI Not There Yet For SysML

For chip architects and designers, the SysML dialect of UML could be useful, but the ROI hurdle is not likely to be scaled in the near future.


At some point down the road in the realm of system-level design, the Systems Modeling Language (SysML) dialect of the Unified Modeling Language (UML) standard may drive into semiconductor design. So far, however, a return on investment has not been established for its use.

SysML is defined as a general-purpose visual modeling language for systems engineering applications, and it supports the specification, analysis, design, verification, and validation of a broad range of systems and systems-of-systems. That includes hardware, software, information, processes, personnel, and facilities.

For the most part, SysML today is leveraged as an enabling technology for the concept of model-based systems engineering, which emphasizes the application of rigorous visual modeling principles and best practices to systems engineering activities throughout the system development lifecycle. This would include, among other things, creation of a fully executable specification of a design.

“To be fair, we are still trying to do RTL signoff, so RTL is probably the closest to what we have as a fully executable specification,” said Frank Schirrmeister, senior group director of product management in the system and verification group at Cadence. “But even that is limited in its view.”

The industry has been working on moving up in abstraction for decades, and since that time, a couple of things have happened, said Schirrmeister. “IP reuse has taken over. You’re using much more IP than anybody would have imagined, and that’s a good thing too because otherwise we would have had a real issue with productivity.”

As part of the move to a higher level of abstraction, Schirrmeister sees two distinct pieces to the puzzle: the blocks in the system, and separately, the system assembly. “In both cases, we have made significant progress to move upward to a next level. The level today is high-level synthesis becoming more and more mainstream for new blocks and for IP you want to re-use at a higher level.”

Cadence isn’t the only company to recognize this. Last week Mentor Graphics reeled in Calypto, the leading high-level synthesis provider.

As the diagram below shows, there are a number of ways to go about this.

(Source: Cadence)

(Source: Cadence)

“The common theme shown here is that except the edges — the pure implementation in hardware, or the pure implementation in software — all others are implementing from a higher-level description to implement these blocks. High Level Synthesis, UML into C, a description like the NML description which abstracts the processor, or the LisaTek description; even Tensilica has language for the extension. The common theme is that you are moving upwards and you are creating a higher level spec,” he explained. [LisaTek was acquired in 2003 by CoWare. CoWare was subsequently acquired by Synopsys in 2010.]

“Is that already an equivalent of what we were all dreaming of 15 years ago, which was, ‘Can we get to a UML specification and everything aligns from there?’ It’s a step in that direction, but we’re not there yet. This is new functionality and new blocks,” Schirrmeister continued.

System assembly adds another set of issues. “You need to implement, define and automate the integration of the blocks. If I now have the bundle of blocks coming from the implementation I have chosen, now I need to integrate it all together. There are a couple of aspects there: the mechanics of it — as an industry we are getting there with things like IP-XACT — and with things like ARM’s acquisition of Duolog. We are getting to the point where at least for the subsystem level and beyond, you do the system integration and you automate the assembly of the RTL,” he said.

Complexity challenges of UML/SysML
Mentor Graphics has done a fair amount of work on UML and SysML in conjunction with customers, according to Jon McDonald, technical marketing engineer. “At least three or four years ago we had a number of customers whose system engineers were using UML and they wanted to go from their system engineering environments into their hardware design architectural environments. They were using SystemC for the hardware architectural work and were using a mix of different UML/SysML-based tools. Mentor has a UML based tool that was in use at a couple of customers so we had created an interface to create the SystemC structure from the UML.”

Interestingly, they found that there is nothing defined in UML or SysML that does not have a one-to-one mapping in SystemC, he explained, which means SystemC has the flexibility to model everything that would be represented in UML or SysML.

While engineering teams were excited about this approach of going from UML to an initial architectural specification, it was readily apparent that the system engineers were not doing a complete spec, McDonald said. “They were incomplete on the specification. They weren’t adding any function. It was just a document. They were using UML like a documentation language, where it is just a description of what I think I want the system to look like. But it is not consistent, it is not complete, it is not executable, it is not totally fleshed out. It’s just a whiteboard representation of what we think we want. But when you come in to SystemC and start doing the architecture, that doesn’t work. It’s got to be complete. You’ve got to have everything defined, all the interfaces have to actually be correct, and you want to have some functionality behind things.”

The problem with that approach is that the system engineer could over-specify the implementation, tying the hardware architect to something that doesn’t make sense or is non-optimal. “In a certain sense, you want the spec to be a little bit ambiguous because what you’re going to implement is going to be based on hardware and system tradeoffs that the system engineer may not know at that point,” McDonald said. “What people are doing today is using UML as a documentation specification language that is very incomplete and definitely not an executable specification.”

What’s also interesting is that there’s nothing technically that prevents SysML from being an executable specification today. Still, McDonald doesn’t believe UML is the right executable language. “It needs to be a simulation language underneath that becomes the glue and the plumbing point that UML and other things come into. The best option for that is SystemC because it is flexible and easy to use and standard, and it’s C++.”

However, just because it’s possible, doesn’t mean it’s the best course of action. It doesn’t make sense to create a completely executable spec if the system details aren’t known at the outset. Might it be overkill to have a fully executable spec from the highest level of abstraction?

For a lot of systems designers today, it definitely is, McDonald pointed out. “They don’t have the system fully defined at that point, and if you think about it, everything is a continuum. So when you start, you don’t know what you’re going to build. Some system engineer is trying to put things together and trying to bring some order to the chaos and create some kind of partitioning and communication and some kind of structure that you can then start filling in the details on. That is what UML is giving you – that structure and definition. There is potential to leverage what is done in UML and bring that into the downstream processes much like they do in software. UML usually doesn’t define the full function. It defines the interfaces, so it should define the interfaces that represent hardware blocks as well as software modules. That’s useful.”

Outside of hardware, UML in particular is much more useful. “UML especially is used much more on the software side today. It is useful for hardware and looking at where people are trying to go. What we’ve been doing over the past five or ten years where we’ve been trying to do ESL, we’ve been moving the level of abstraction of the executable specification up and trying to get a higher and higher level of executable specification so that we can more quantitatively define what the system should be earlier but there’s a limit how far up you can go, because you can’t fully definite that system before you know what it is,” he said.

How high is too high?
Many engineering teams today are trying to push up the level of abstraction in order to make more-informed decisions architecturally, ultimately tying into what the system engineers are doing whether that be UML or SysML or Matlab. “Being able to push up into those areas and leverage what people are defining up there is important and valuable. And over time, engineering teams we’ve worked with say one of the big things they see as valuable is not necessarily the float down of information – that’s nice and convenient – but when information starts to flow back up, as well. The system engineers make a choice. They have this blob of whatever they send down to downstream. Now when the system engineer starts to get feedback it tells them, ‘You have this function; it’s going to take this many resources, it’s going to be this fast it’s going to take this much power, it’s going to have all these attributes that come back from the initial potential implementation.’ Now that starts to be really valuable for them because now those decisions that are made at the architectural implementation level can start to be verified against the system constraints as early as possible,” McDonald added.

This is all well and good, but the challenge is going to be the ROI, said Drew Wingard, CTO of Sonics. “How do you get to the point where the cost in creating the model is paid back with learning something earlier, or being able to make tradeoffs in a better fashion — essentially getting things done at lower overall cost?”

Another challenge with technologies such as SysML is that they target the narrowest part of the pyramid designers, he observed. “It speaks to the people doing the architecture work. They don’t tend to produce deliverables that are easily usable by others downstream in the flow of designing the hardware, or necessarily even upstream in terms of writing the lowest levels of the device software stacks and stuff. That’s been the biggest challenge, and we’ve got a long history in the EDA side of our industry of not seeing architecture tools ever really get funded because there’s never a big enough market to fund them. It’s not that they don’t add value. It’s that to get over the hump to adding value requires so much investment it’s not clear you could ever get back.”

One place where one could imagine SysML being used is a company that wanted to stamp out a bunch of designs. In this scenario, they could leverage the investment across many designs over a relatively short period of time, such as microcontrollers or microcontroller-based IoT kinds of devices, Wingard said. “What they’ve done in the past is simply over-design, and if you can afford to over-design, then all this higher level of abstraction stuff doesn’t actually buy you much. This higher level of abstraction stuff is very useful when you’re trying to make real tradeoffs, and we’re just not seeing that at this point.”

Finally, the increasing cost of mask sets works against the idea that higher-complexity designs will be used to stamp out a bunch of different chips.

What it boils down to for the use of UML/SysML in the semiconductor design process today is that the benefits of the technology don’t justify the cost of the effort in most cases. This may change in the future, but current efforts appear to be better spent in other areas of architectural optimization.

  • Yves BERNARD

    Globally, I can subscribe to this point of view. However the explanation of why building SysML model is so expensive today and of why the ROI is so low is missing. IMHO, key points are:

    1. We are drastically missing libraries of SysML model components. Compared to software engineering, building a SysML model today is more or less like writting C or Java code without any libary of functions or classes. What would be the productivity of C or Java without them?

    2. SysML – just like UML – is *not* an executable language. Up to very recently with publication of fUML (foundational UML), any executable interpretation of a SysML model relies on proprietary and rarely well documented extensions. And even with fUML, only a very restricted subset of SysML is covered at that time.

    However things are evolving and voices of people more interested by the executability aspect of SysML are welcome at the OMG. They will help us in improving its potential.

  • Kev

    Some of the architectural level stuff and at lower levels you want to trade off hardware vs software, so you really want a complete software description of your system rather than a mix of executable and non-executable stuff. So C/C++ extended for hardware description is probably a better bet than any flavor of UML.

    NB: SystemC is not an extended C++, and its abstractions are bad.

  • Ann Steffora Mutschler

    Thanks to both of you. Those are very good points. What’s clear is that the potential is there. How it evolves is the part that isn’t clear.

  • Juha-Pekka Tolvanen

    One possible direction is towards domain-specific languages (as opposite to general-purpose ones). In software development side that change is already happened when it comes to using
    models for something else than sketchng and documentation only.

    On example if this approach targeting SystemC is illustrated at illustrating that modeling concepts are not SysML (or UML) but concepts of the particular system.

    The good side is that when having a full control on the language and generators you can get out of the models what is needed (as opposite if language is fixed and general purpose), and the output can also provide execution. The bad side is that you need to define first what you are looking to get from the models. This calls for an investment and expert thinking. Luckily tools have evolved here a bit so defining domain-specific langauges has become much easier (no lexx and yac, compiler development etc