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 3, 2020
[From the last episode: We looked at CNNs for vision as well as other neural networks for other applications.] We'€™re going to take a quick detour into math today. For those of you that have done advanced math, this may be a review, or it might even seem to be talking down...
Jul 2, 2020
Using the bitwise operators in general -- and employing them to perform masking, bit testing, and bit setting/clearing operations in particular -- can be extremely efficacious....
Jul 2, 2020
In June, we continued to upgrade several key pieces of content across the website, including more interactive product explorers on several pages and a homepage refresh. We also made a significant update to our product pages which allows logged-in users to see customer-specifi...

Featured Video

Product Update: New DesignWare® IOs

Sponsored by Synopsys

Join Faisal Goriawalla for an update on Synopsys’ DesignWare GPIO and Specialty IO IP, including LVDS, I2C and I3C. The IO portfolio is silicon-proven across a range of foundries and process nodes, and is ready for your next SoC design.

Click here for more information about DesignWare Embedded Memories, Logic Libraries and Test Videos

Featured Paper

Cryptography: Fundamentals on the Modern Approach

Sponsored by Maxim Integrated

Learn about the fundamental concepts behind modern cryptography, including how symmetric and asymmetric keys work to achieve confidentiality, identification and authentication, integrity, and non-repudiation.

Click here to download the whitepaper

Featured Chalk Talk

Benefits of FPGAs & eFPGA IP in Futureproofing Compute Acceleration

Sponsored by Achronix

In the quest to accelerate and optimize today’s computing challenges such as AI inference, our system designs have to be flexible above all else. At the confluence of speed and flexibility are today’s new FPGAs and e-FPGA IP. In this episode of Chalk Talk, Amelia Dalton chats with Mike Fitton from Achronix about how to design systems to be both fast and future-proof using FPGA and e-FPGA technology.

Click here for more information about the Achronix Speedster7 FPGAs