The Missing Link

By Jon McDonald
When something comes up once it may be an anomaly, but when the same thing comes up multiple times in a short period of time there’s a good chance it is a more general trend.

At Mentor we have tools focused on Systems Engineering and UML/SysML, as well as SystemC ESL/TLM focused tools. We have invested effort in integrating the tool flows, but I had not seen significant drivers for a combined flow. Recently I’ve been involved with three customers deploying very similar UML/SysML-to-SystemC combined flows. Through these interactions it has been interesting to see how the users in the various groups are focusing on their particular portion of the design space and applying their bias to the other space.

The flow that is emerging at all three customers has the systems engineers using UML/SysML to specify the system in much the same way they have been doing the specifications since beginning to use UML/SysML. From the UML/SysML they then generate a SystemC model for use as the initial functional core, which can be used to start the architectural model in the SystemC ESL/TLM domain. The model that is created in SystemC from the UML/SysML is a direct 1-to-1 mapping of the UML/SysML to SystemC; the initial SystemC model will simulate and can be verified to behave as defined by the original UML/SysML description.

There were a number of challenges in achieving a flow from the UML/SysML to the SystemC. First, not all of the UML/SysML was targeted to SystemC. Only those portions that were potential targets for hardware implementation were targeted to the SystemC. Second, the systems engineers had to spend some time to ensure that the UML/SysML they were creating was complete and consistent. Previously they had been using the UML/SysML for documentation and some of the initial specifications were incomplete or inconsistent. In attempting to execute the models in the SystemC, domain errors in functionality or completeness became very obvious. And third, a good deal of discussion focused on ensuring that the systems engineers were not implying architectural restrictions that were not required by the target systems. Achieving this required the systems engineers to focus on the requirements of the system, attempting to keep the UML/SysML descriptions independent of the implementation choices.

In the SystemC domain the focus was on taking the abstract functions and beginning to partition the elements into a potential architectural solution. At this point the architectural possibilities could be explored, beginning to map the abstract sc_interface-based communication to specific TLM2.0 communication paths and implementations surrounding the UML defined messages.

Through the course of these exercises it struck me as interesting that the issues and changes in perspective required to effectively move back and forth between the UML/SysML domains and the SystemC/TLM domain are very analogous to the change in perspective required in moving from RTL to SystemC/TLM. Ultimately I believe tremendous value can be derived from streamlining the flow from the Systems, to Architecture, to Implementation. Each stage can leverage the previous and jumpstart the following stage. Significant investment has been made in the ESL link to RTL. I believe the Systems to ESL link is ready for investment, as well.

–Jon McDonald is a technical marketing engineer for the design and creation business at Mentor Graphics.