This is part seven in a series. Read part six here. 

When we talk about emulation, we usually talk about digital logic that is expressed in RTL form and then populates the gates in the emulator. And there’s lots of that logic to be had, so that’s fine as far as it goes.

But, more than ever, digital logic must interact with real-world systems that are analog in nature. And many of those systems can be modeled – just like digital systems can be. The difference is that these models often leverage a continuous-time implementation instead of discrete. They’re variously referred to as mathematical, continuous-time, or mechatronic models.

The focus on revolutionizing the automobile is part of this, since electronic control units (ECUs) in cars typically connect up to mechanical components. But you can also find such models in, for example, the industrial internet of things, where increasingly diverse sensors and actuators connect to mechanical equipment.

In addition, there are discrete-time applications – digital signal processing (DSP) – that may also have mathematical models that are more sophisticated or abstract than what is possible to express in RTL.

Connecting these types of models up to Veloce emulators is straightforward. And it can provide a much more thorough verification exercise than the more typical use of select scenarios expressed in SystemVerilog. But exactly how you include such models in your emulation plan depends on the origin of the models.

Matlab Models

Matlab is a very popular tool for modeling real-world phenomena in an abstract, mathematical way. It can be used both for discrete-time DSP models and for continuous-time mechatronic or other mathematical models.

There are three possible ways to connect such a model to a Veloce emulator.

1. Native Matlab co-simulation. This requires access to Matlab during the emulation; the emulator connects to the model via the direct programming interface (DPI). You would, of course, need a Matlab license in order to run the model; Matlab itself would be executing on the host computer as its own separate process, running alongside other elements of the testbench.
2. Export an HDL model. This allows you to use the model without running an instance of Matlab. Instead, you export an HDL version of the model using Matlab’s HDL Coder feature, which requires its own feature license. The model is then either simulated or emulated as HDL.
3. Export a C model. Similar to the prior method, this leverages the Matlab Coder feature, which, again, requires a feature license. The C model can be connected to the emulator using the DPI interface.

Amesim and Others: FMUs and FMI

Tools like Siemens’ Amesim can also be used to generate mathematical models for use in emulation. But these programs rely on a different exchange format for the models that connect to Veloce. This format is a well-accepted industry standard, backed not just by Siemens, but Bosch and dozens of other companies.

There are two parts to these models. First, there is the notion of the Functional Mockup Unit, or FMU. You can think of this as a block-box model of whatever function is needed. It consists of C code and an XML file.

Access to the FMU comes via the Functional Mockup Interface, or FMI. FMI is an API that encapsulates or wraps the FMU. It’s based on an open standard, meaning that FMUs can then be incorporated regardless of the tool used to generate them. As long as they abide by FMI, then any simulation or emulation environment that speaks FMI can access the model. FMI is also device-independent, making the models portable across verification systems and hosts.

There are two types of FMU.

• Model-exchange version. Its intent is to provide the mathematical definition portion of the model only. If you’re using this model, it’s assumed that you will have your own solver that’s able to interrogate and exercise the model. If you’re simply trying to provide the model to teams that already have their own tools for executing the models, then this is the best format for you.
• Co-simulation version. This version is better suited to verification and co-simulation. It includes the solver along with the mathematical model, making it self-sufficient as an executable unit that can be integrated into the testbench.

Note that Matlab doesn’t support FMUs directly. You can, however, create a C model and then use a separate tool to convert that C model into a full-fledged FMU. Or, absent such a tool, you can hand-code a C wrapper and an XML file.

Plugging in the Models

Regardless of the model type – Matlab native, Matlab HDL, Matlab C, or FMU – they all connect to the Veloce emulators over the SCE-MI interface that allows higher-level abstractions and transactions to be communicated back and forth efficiently between the testbench on the host computer and the emulator.

So, as the number of systems connecting to mechanical and analog components ramps up, models of those components are becoming an important aspect of verification and validation. Emulators will be able to do a much more thorough, realistic job if they can rely on sophisticated, accurate models of how the connected components will behave. Signals from the models will serve as more realistic stimulus for the logic in the emulator, and outputs from the emulator can drive the component models in order to verify that the components behave as expected in response to those outputs.

Mathematical models are yet another way in which the testbench can more accurately represent the world to which the emulated circuit will be connected. Because the models connect to Veloce emulators using the standard interfaces that verification engineers are already familiar with when running emulation, the barrier to using them should be low.

This will be an increasingly important way to verify complex integrated circuits to ensure that they behave correctly in the exploding automotive and industrial equipment segments.

John Stickley, Emulation Technologist, Mentor Emulation Division, Mentor, a Siemens Business

John Stickley is a verification technologist in Mentor’s emulation division. His research interests are in virtual platforms for system-level modeling and design verification. His most recent work at Mentor has been in the area of high performance co-modeling techniques used to bridge hybrid testbenches with designs under test modeled in RTL languages. He has 25 years of experience in the EDA industry and holds a BSEE degree from Cornell University.

Mentor, A Siemens Business

www.mentor.com/company