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/
