In the design process of analog/mixed-signal (AMS) ICs, there are quite a number of languages used in the front-end of the design flow (that is the phase before the physical implementation starts): languages to describe the analog and digital hardware (like Verilog-AMS, Verilog, VHDL), languages dedicated to verification for the creation of test benches (such as Universal Verification Methodology/UVM, SystemVerilog, Property Specification Language/PSL), languages to support the IP integration process (e.g., IP-XACT), and languages for the creation of behavioral or system-level models (in SystemC, SystemC-AMS). These languages are being developed in consortia where the electronics and semiconductor industries, electronic design automation (EDA) companies, and research and academic organizations collaborate to define an industry accepted and supported language standard.
Examples of such standardization consortia are the Accellera Systems Initiative and the IEEE Standards Association. Also NXP is member of these organizations, to be able to steer the developments of design automation standards which are essential in the product creation process.
With the growing complexity of the mixed-signal ICs, most design teams follow a divide-and-conquer approach: the analog functionality is developed by the analog engineers, the digital functions by the digital team, and in some cases there is a dedicated team working on the embedded software. You can imagine each team has its own way-of-working, design methods and they use different languages to describe the function they what to implement. Do they use and speak the same language? Probably not, as analog behavior needs a different description language than digital or software functionality. Should they speak the same language? Preferably yes, as analog and digital functions gets more and more intertwined and a common understanding of the overall AMS functionality is required.
However, in practice we see that there are separate analog, digital and software teams active to create and contribute their part to the overall chip, all using different languages. How do we guarantee that the combination works? Luckily, in most projects there are system architects and engineers involved, which are in charge of the overall system architecture and functionality. And yes, also they use their own language, a system-level language. Furthermore, dedicated verification engineers are creating tests and testbenches to verify and validate the IC, to check the functionality and integration, before silicon is ordered. Also they use a language which is most suitable for chip integration and verification.
You can imagine that a single IC design and verification language would be nice, but is very unrealistic seeing the different disciplines involved. Fact is that each design team has to deal with the multi-language nature in the mixed-signal IC design and verification process, which sometimes also results in incompatible or even conflicting language constructs or semantics…
We face this multi-language challenge not only in NXP; also other semiconductor industries are dealing with this. Fortunately, the standardization organizations like Accellera Systems Initiative or IEEE-SA come to rescue: as part of ongoing language standard developments, they will address the multi-language challenge. As member of the Accellera Systems Initiative, NXP will contribute to a Birds-of-a-Feather meeting planned at the upcoming Design Automation Conference (DAC), to discuss the development of the next generation analog/mixed-signal language standards.
What is your experience with using different design and verification languages? Which route do you think we should go? Let’s see if we can agree on speaking the same language – I bet it will be English.