feature article
Subscribe Now

Standardising on Analogue

Have you ever wanted to spend vast amounts of time in a conference room, real or virtual, arguing about the precise meanings of words? Trying to accommodate the strongly expressed and sometimes incompatible views of people, some of whom know less than they think they do about the subject in hand, a subject you are knowledgeable on and feel strongly about? When you have reached a conclusion, are you then happy to sit back for months, while even more people express even more views on how you got it wrong, how what has emerged doesn’t meet the needs and how you really shouldn’t have bothered even starting? And then when all these views have been consolidated and the final product appears, are you quite happy to buckle to and start the whole thing again?

You are?

There is a place waiting for you in the wild and whacky world of standards.

Let me give you a for-instance:

At the (DATE) Working Group meeting, a first list of suggestions for new features in (SUBJECT OF STANDARD) was discussed and a process to handle them was presented:

1. Define suggestions
2. Define project champions and related study groups
3. Convert suggestions to requirements (white papers)
4. Define priorities (working group vote on white papers)
5. Develop language changes or new packages
6. Review language changes or new packages in working group and vote
7. Proceed to an IEEE ballot for approved changes and packages.

When I was in PR, I used to write press releases, or rather draft them, and then watch while everyone and their dog had their go at “improving” them. At least there was a cut off point, where the release went out into the world and then it was finished. By contrast, developing standards is rather like painting the Forth Bridge: a task which allegedly keeps a team of painters involved forever, since as soon as they reach one end they go back and start again – but see the Wikipedia entry.

What brought on this moment of introspection was looking at the draft standard for AMS extensions to SystemC. This was published in December, and comments are needed by the end of March, just over a month away and just over two years since the drafting started. By the standards of standards groups this is meteoric progress.

The issues of integrating Analog and Mixed Signal into the digital design flow were discussed by Bryon Moyer last autumn. He looked at both the architectural and implementation levels. At the implementation level there are VHDL-AMS and a Verilog AMS: these are both specified and in use. However, there is nothing widely available to describe systems at the architectural level. SystemC-AMS is designed to fill the gap.

The idea behind the work is expressed in the Open SystemC Initiative (OSCI) AMS Working Group’s charter:

… to enable specification, verification, implementation of … systems containing digital, analog, mixed signal and radio frequency functions…in electrical and non-electrical domains.

Being well-trained engineers, they defined objectives and use cases and created a requirements specification. They also developed a glossary of the terms and acronyms that they were using, and there were a great many of these.

A few words about what SystemC AMS is not. It is not for circuit level simulation – Spice and other tools exist to do that. Nor is it for behavioral modelling or HDL language – for that, SystemC AMS hands architectural models to Verilog-AMS and VHDL-AMS.

What it aims to do is to provide a single environment for modelling the AMS elements of an SoC alongside the digital elements. It is an extension to the increasingly widely-used SystemC language, and the use cases are that it should produce executable specifications, be used for architectural exploration, provide integration validation, and be used for virtual prototyping. The Working Group sees that the first use of the AMS extensions will be in automotive, telecoms and image-sensing applications.

The list of requirements was graded from high (H) “basic to the language,” through medium (M) “valuable but not essential in at least the first draft of the language reference manual (LRM),” to low (L), “nice to have but could well be developed elsewhere.” A number of the M requirements related to non-electrical functions, which were deliberately left out of the first draft. However the draft, as well as including all the H requirements, still managed to include a large number of the M requirements. Many of the L functions were later decided to be user defined and can be supported by user-created libraries built from elements within the language.

So what does this draft actually include? The press release summarises it as:

 …new class libraries layered on top of the SystemC standard with focused AMS system-level modeling and simulation capabilities. These dedicated libraries provide features which can be applied in combination with digitally oriented ESL design methods. The AMS draft language reference manual details these new language constructs by proposing predefined modules, interfaces, channels and ports, and introducing new execution semantics for efficient simulation of discrete- and continuous-time behavior.

Looking at this more closely: at the bottom, there are electrical primitives, resistors, inductors and capacitors, and models of the sources and sinks needed to create analog signals. With these, it is possible to describe Electrical Linear Networks (ELNs), one of three elements of an AMS description. Add to these model semantics and predefined models for embedded linear functions, and it becomes possible to describe linear static functions and non-linear dynamic functions. These allow the creation of Linear Signal Flow (LSF) and Timed Data Flow (TDF), the other two elements of an AMS description. Actually, that’s not strictly true; SystemC AMS also encourages user-defined extensions for describing additional modules, ports and signals. The standard uses a naming convention that is aligned with those of the AMS extensions of Verilog and VHDL as well as those used in Spice and SystemC.

Discrete-time and continuous-time descriptions have to be modelled differently, but the standard provides computation-independent assignments and methods, using common ports, nodes and channels. The model hierarchy uses the concepts defined in IEEE 1666, (SystemC).

Synchronization, both within the analog domain and between the analog and digital regions, is clearly important, and, to simplify matters, the draft standard is not addressing asynchronous events. It proposes channels as the means of both communication and synchronization. The Timed Data Flow has preset sampling times to take data from the discrete domain, and, similarly, analog events are reported back into the discrete domain at fixed time steps.

Two models of computation, non-conservative and conservative, are defined. In the non-conservative domain, TDF and LSF provide data flow and signal flow descriptions, and TDF supports static scheduling and multi-rate data flow. The conservative domain supports a linear solver, but the M level requirements for embedding dedicated solvers, together with an appropriate API, and for small-signal, large-signal, and other non-linear solvers, have been left out of this draft.

The standard uses the existing C++ capabilities to read/write from files and the standard #include for variables. It defines a method for AMS signal tracing and a trace file format for both VCD and tabular files.

While it might sound like a statement of the obvious, since this is supposed to be an extension to SystemC, it supports all standard SystemC data types and, as described in the press release, introduces classes for complex numbers and for vectors and matrices.

If you are interested in AMS at the architecture level, then this is your opportunity to influence the outcome of what should be an important tool for creating the next generation of complex ICs. Download a documentation pack, which includes the draft standard, examples, and supporting documentation, from the SystemC AMS working party web site, (www.systemc-ams.org/) and see if there are things you agree/disagree with. The site has a forum and all the usual links. The Fraunhofer IIS also has a useful SystemC AMS site at systemc-ams.eas.iis.fraunhofer.de/

Leave a Reply

featured blogs
Jul 25, 2021
https://youtu.be/cwT7KL4iShY Made on "a tropical beach" Monday: Aerospace and Defense Systems Day...and DAU Tuesday: 75 Years of the Microprocessor Wednesday: CadenceLIVE Cloud Panel... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Jul 24, 2021
Many modern humans have 2% Neanderthal DNA in our genomes. The combination of these DNA snippets is like having the ghost of a Neanderthal in our midst....
Jul 23, 2021
Synopsys co-CEO Aart de Geus explains how AI has become an important chip design tool as semiconductor companies continue to innovate in the SysMoore Era. The post Entering the SysMoore Era: Synopsys Co-CEO Aart de Geus on the Need for AI-Designed Chips appeared first on Fro...
Jul 9, 2021
Do you have questions about using the Linux OS with FPGAs? Intel is holding another 'Ask an Expert' session and the topic is 'Using Linux with Intel® SoC FPGAs.' Come and ask our experts about the various Linux OS options available to use with the integrated Arm Cortex proc...

featured video

Design Success with Foundation IP & Fusion Compiler

Sponsored by Synopsys

When is 1+1 greater than 2? When using DesignWare Foundation IP & Fusion Compiler! Join Raymond and Yung in their discussion of a customer that benefited from the combination of Fusion Compiler’s machine learning and Foundation IP cells and macros.

More information about DesignWare Foundation IP: Embedded Memories, Logic Libraries, GPIO & PVT Sensors

featured paper

PrimeLib Next-Gen Library Characterization - Providing Accelerated Access to Advanced Process Nodes

Sponsored by Synopsys

What’s driving the need for a best-in-class solution for library characterization? In the latest Synopsys Designer’s Digest, learn about various SoC design challenges, requirements, and innovative technologies that deliver faster time-to-market with golden signoff quality. Learn how Synopsys’ PrimeLib™ solution addresses the increase in complexity and accuracy needs for advanced nodes and provides designers and foundries accelerated turn-around time and compute resource optimization.

Click to read the latest issue of Designer's Digest

featured chalk talk

Microwave/Millimeter Cable Assemblies and Interconnects

Sponsored by Mouser Electronics and Samtec

Cabling and connectors for RF design are critical to performance. And, in the world of microwave and millimeter-wave design, choosing the right interconnect for your frequency band is key to signal integrity. In this episode of Chalk Talk, Amelia Dalton chats with Matthew Burns of Samtec about what you need to know to choose the right interconnect solution for your next RF design.

Click here for more information about Samtec Precision RF Connectors & Cable Assemblies