Reusing Existing Descriptions with New Languages
New languages and descriptions are a key part of moving the state of the art forward in a given domain. New languages align the abstraction level of the description with the problems being solved – for example, SystemVerilog brought object-oriented programming techniques into the hardware-description domain to address the challenge of verifying complex designs. The Portable Test and Stimulus standard being developed by Accellera brings new capabilities to describing test intent that is usable across verification platforms and test-abstraction levels.
New languages face a well-known challenge, though: on Day 1, very little content will exist in the new language. Meanwhile, a huge amount of intellectual property will exist in other languages. In some sense, it’s tempting to term this ‘legacy’ code, but it’s really just existing code. When developing a new language, a primary concern is to what extent this existing code can be leveraged alongside content written in the new language.
In some cases, the new language is a superset of an existing language, allowing existing code to be directly used within new descriptions. Both SystemVerilog and C++ originally adopted this model. This made it very easy for users with C code, for example, to begin adopting features of C++. One downside of this approach is that existing code often uses patterns and approaches that are discouraged in the new language.
Due in part to its long history, the C language has always been a bit of a lingua franca when it comes to leveraging existing descriptions within new languages. Almost every new language introduced over the past few decades has supported interoperability with existing C code and code that can be called via a C API. Just a sampling of new languages that have supported calling C code include C++, Java, C#, TCL, PERL, Python, Verilog, VHDL, and SystemVerilog.
The ability to use existing descriptions was a key concern during development of the Accellera Portable Test and Stimulus language, and the emerging standard provides several mechanisms to enable reuse of existing descriptions. One of these, not surprisingly, is a mechanism for calling external C functions. This mechanism is very similar to SystemVerilog DPI, VHDL’s foreign-language interface, and the Java Native Interface (JNI).
Here a short example, which is a simple C API for setting filter coefficients and then initializing the filter:
In SystemVerilog, we can access these functions from SystemVerilog via the Direct Procedural Interface (DPI). To do so, we specify import functions declarations in SystemVerilog:
With the Portable Test and Stimulus domain-specific language, we can also specify import declarations to enable access to the external C API:
Now we can access the external C functions from our Portable Test and Stimulus description, as shown below. The Portable Test and Stimulus description specifies that a random device configuration will be selected by the tool (rand device_cfg), while the content of the exec block specify what external activity should occur. In this case, a sequence of calls to the C API.
The Accellera Portable Test and Stimulus standard is coming, and the procedural interface provides an easy way to access existing functionality on written in C (or any language that provides a C interface) from descriptions written using the new standard. For more information on Portable Test and Stimulus, please see the Portable Stimulus Basics course on Verification Academy. If you’re interested in learning more about the facilities the Portable Test and Stimulus standard will provide for reuse, please see my paper “Making Legacy Portable with the Portable Stimulus Specification”.
https://verificationacademy.com/courses/portable-stimulus-basics
Comments