V-AMS Compact Modeling Extensions subcommittee Minutes of May 6, 2003 Attendees: Geoffrey Coram, Analog Devices Ilya Yusim, Cadence Jeroen Paasschens, Philips Rick Poore, Agilent John Moore, Agilent Colin McAndrew, Motorola Srikanth Chandrasekaran, Motorola David Zweidinger, Texas Instruments Marek Mierzwinski, Tiburon Boris Troyanovsky, Tiburon Patrick O'Halloran, Tiburon Peter Liebmann, Xpedion Han Koh, Xpedion Mustafa Sungur, Nassda Wolfgang Roethig, NEC Gary Fedder, Carnegie-Mellon University Ken Bakalar, Mentor Graphics Wei-Dong Liu, Synopsis 1. Introductions Attendees discussed their involvement with Verilog-AMS; the two main camps were (a) those in device modeling groups that do the hand-coding in C and (b) those in simulator groups implementing Verilog-AMS for customer use. 2. Committee guidelines The following items were listed as general guidelines for the subcommittee: - Recommend as little as possible, meaning that we prefer general solutions that address multiple needs. - Eschew analysis- or simulator-specificity where possible. Note that all recommendations will be sent to the full Verilog-AMS technical committee (and then upwards within Accellera) for final approval. 3. Goals The attendees were asked, "What should an extension for device modeling do?" Geoffrey Coram: Extensions should help make a device model written in Verilog-AMS as efficient and fast as one coded natively in C/C++ Ken Bakalar: Extensions should make implementations portable by using formal precision in specifying to the simulator what they mean/should do. Mustafa Sungur asked if the extensions should help speed up model development or speed up the run-time performance. Colin McAndrew said that by allowing re-use of modules, this will speed up the development, but the main goal of the subcommittee should be the run-time efficiency and removal of errors in implementation (perhaps due to ambiguous specifications, as per Ken's point) Wolfgang Roethig agreed that the extensions should facilitate writing portable, reusable models. Someone asked if we had contact with model developers; in some sense, the non-EDA people (TI, Analog Devices, Philips) are responsible for model development, but the point was more towards research groups writing new models. Colin listed several models at universities that are being written in Verilog-AMS, and said that the Compact Model Council (CMC) members had expressed interest. Marek Mierzwinski mentioned that the BSIM group at Berkeley is considering using Verilog-AMS, but the CMC wants models in C The extensions are mainly for improving speed, but also "convenience items" that the model developers have gotten accustomed to using. 4. Technology donations Colin is trying to get ADMS released into the public domain, either through "SourceForge" or this subcommittee. Someone pointed out that this committee is not really about developing software. However, the ADMS platform may be a useful example for us to evaluate how powerful a proposed extension is. 5. Digression into attributes Peter Liebmann suggested that we look into attributes in Verilog2000 as a possible way to implement many of the proposed extensions. Someone pointed out that we really haven't generated a list of the extensions yet. Ken gave a quick tutorial for attributes, that they are sort of a magic comment that simulators may ignore (if they don't recognize) because they should not affect the results, only perhaps the efficiency. Wolfgang was concerned that attributes were poorly controlled and could introduce non-portability issues if they were implemented differently. Does "bias-independent" have a clear meaning, if it were used to label a named block to indicate that the expressions need not be recomputed each iteration? We need to codify some attributes to get portability. Also, he suggested that we look at other extensions that define semantics, such as in SystemVerilog. Ken metioned that there are other methods of syntax extensions besides attributes. 5. Suggested enhancements Srikanth Chandrasekaran suggested that we make up a list of problems we are trying to address. To that end, Geoffrey asked that anyone with a list of suggested enhancements e-mail them to him. Many contributions are already collated at http://www.designers-guide.com/private/vams-extensions/compact-modeling/index. html Geoffrey hopes to generate a comprehensive "wish list" and then eliminate things that have insufficient justification for a language extension. (In an earlier context, Mustafa was urged to suggest extensions that would help a model run better in high-capacity simulators like Nassda's HSIM.) Wolfgang asked if the VHDL analog working group had done any work in this area, and if we could review it for applicability. Ken said he didn't think there was any such work. (If you know differently, please let Geoffrey know.) 6. Current implementations David Zweidinger asked about the memory efficiency for ADMS, Tiburon. What he's read has only addressed speed, which is slower but perhaps acceptably so. His company is already having memory problems with native C models for top-level sims. Boris Troyanovsky said he didn't think it would be an issue, because there were ways to improve the memory use; however, Colin and Boris admitted that they have not done formal benchmarking. 7. The next subcommittee meeting is set for Tuesday, May 20 at the same time, 11 AM US-Eastern Daylight Time (8 AM US-Pacific Time) Wolfgang mentioned this was difficult for his company's modeling group in Japan; however, since they did not contact Geoffrey, he is reluctant to inconvenience those in Europe who did contact him. If there are people from Asia who are interested, we may push subsequent meetings to one hour later, 12 noon EDT (9 AM Pacific). Srikanth asked that everyone in the call sign up for the Verilog-AMS e-mail reflector. To subscribe, send e-mail To: Majordomo@eda.org with the command in the body: subscribe verilog-ams your_address@company.com The participants were all BCC'ed; if you got two copies of these minutes, you're probably already on the reflector.