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.
