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
May 19, 2022
The current challenge in custom/mixed-signal design is to have a fast and silicon-accurate methodology. In this blog series, we are exploring the Custom IC Design Flow and Methodology stages. This... ...
May 19, 2022
Learn about the AI chip design breakthroughs and case studies discussed at SNUG Silicon Valley 2022, including autonomous PPA optimization using DSO.ai. The post Key Highlights from SNUG 2022: AI Is Fast Forwarding Chip Design appeared first on From Silicon To Software....
May 12, 2022
By Shelly Stalnaker Every year, the editors of Elektronik in Germany compile a list of the most interesting and innovative… ...
Apr 29, 2022
What do you do if someone starts waving furiously at you, seemingly delighted to see you, but you fear they are being overenthusiastic?...

featured video

Intel® Agilex™ M-Series with HBM2e Technology

Sponsored by Intel

Intel expands the Intel® Agilex™ FPGA product offering with M-Series devices equipped with high fabric densities, in-package HBM2e memory, and DDR5 interfaces for high-memory bandwidth applications.

Learn more about the Intel® Agilex™ M-Series

featured paper

5 common Hall-effect sensor myths

Sponsored by Texas Instruments

Hall-effect sensors can be used in a variety of automotive and industrial systems. Higher system performance requirements created the need for improved accuracy and more integration – extending the use of Hall-effect sensors. Read this article to learn about common Hall-effect sensor misconceptions and see how these sensors can be used in real-world applications.

Click to read more

featured chalk talk

Multi-Protocol Wireless in Embedded Applications

Sponsored by Mouser Electronics and STMicroelectronics

As our devices get smarter, our communication needs get more complex. In this episode of Chalk Talk, Amelia Dalton chats with Marc Hervieu from STMicroelectronics joins me to discuss the various topologies present in today’s wireless connectivity, and how the innovative architecture and flexible use of resources of the STMicroelectronics STM32WB microcontroller can help you with your wireless connectivity concerns in your next embedded design.

Click here for more information about STMicroelectronics Wireless Connectivity Solutions