Marq, I led with the un-important part of my thought.. sorry. I hope to have a better answer to that at BMAS this fall, but the short answer is: How can my verilog-ams wrapper know which corner is used? I am having to add extra subcircuits to pass the parameter values as signals back up to a level that the wrapper can use them.. I would LOVE to just simply refer directly to a specific parameter value in the model card/paramsets (I trust I will be able to get this info if a compact model/paramset is used.. and use it in ANY arbitrary module.. ) BUT that wasn't the point of my message: I was trying to say that the first paragraph of annex E should be updated to include the fact the Verilog-A compact models can do ALL the same things that spice include does, and a reference should be included to the appropriate other sections of the docs for compact models and paramsets, so readers can find those. ALSO the method for specifying modelfile sections (or libs) (one assumes at the top level) should be specified as well, - unless we are assuming that each simulator will require some unique file to include this info for their simulator? (this was, unfortunately, the message I led with.. Sorry!) Jonathan David j.david@ieee.org jb_david@yahoo.com http://ieee-jbdavid.blogspot.com Mobile 408 390 2425 Work: jbdavid@scintera.com http://www.scintera.com 408 636-2618 ----- Original Message ---- From: Marq Kole <marq.kole@nxp.com> To: verilog-ams <verilog-ams@eda-stds.org> Sent: Wednesday, June 27, 2007 11:57:04 PM Subject: Re: update of Annex E Jonathan, I'm not convinced this is necessary - this goes beyond just supporting the models/subcircuits/primitives which is necessary for using legacy SPICE netlists in a Verilog-AMS top-level. By performing the section includes in the SPICE part of the description the correct (process/global) parameters would be available to the SPICE models/subcircuits/primitives which can be included in the LRM 2.2 way in Verilog-AMS modules. Why do you think access to sections and parameter sets is needed? Cheers, Marq Jonathan David <jb_david@yahoo.com> Jonathan David <jb_david@yahoo.com> 27-06-2007 23:39 To "Geoffrey.Coram" <Geoffrey.Coram@analog.com> Marq Kole <marq.kole@nxp.com> cc verilog-ams <verilog-ams@eda-stds.org> Subject Re: update of Annex E Classification And how to include sections.. I would suggest that we revise the header paragraph to add the mention that ALL device/source models and their parameters (corners, randomization etc) can be supported as verilog-A compact models, and reference the appropriate chapter or annex where that use model is defined. Jonathan Jonathan David j.david@ieee.org jb_david@yahoo.com http://ieee-jbdavid.blogspot.com Mobile 408 390 2425 Work: jbdavid@scintera.com http://www.scintera.com 408 636-2618 ----- Original Message ---- From: Geoffrey.Coram <Geoffrey.Coram@analog.com> To: Marq Kole <marq.kole@nxp.com> Cc: verilog-ams <verilog-ams@eda-stds.org> Sent: Wednesday, June 27, 2007 4:27:28 AM Subject: Re: update of Annex E Marq - The document is there now: http://www.eda-stds.org/verilog-ams/htmlpages/public-docs/merged_spice.pdf I tend to agree about removing diode, etc. I wonder, though, if the Annex should say something about referring to Spice elements, whether they are .model cards or .subckts. It might be as little as "Simulator vendors shall document the methods and restrictions of accessing SPICE .model cards from within a Verilog-AMS netlist." -Geoffrey Marq Kole wrote: > > All, > > I've just asked Geoffrey Coram to upload a new version of the Annex E (SPICE compatibility) document to the Verilog-AMS website for review tomorrow. It should be there under the name merged_spice.pdf. > > Most of the Mantis items mentioned for Annex E have been processed in this document, except for those relating to Tables E.1 and E.2. My proposal is to integrate the tables into a single table that also describes exactly the behavior of each primitive and hence the influence of each parameter. Also, the items requiring a model (diode, bjt, mosfet, mesfet, and jfet) should be removed from the table as they do not appear in Verilog-AMS netlists as a reference to SPICE primitives. So there is no need to pollute the namespace of Verilog-AMS with these names that are not used anyway. > > Would that be acceptable? > > Cheers, > Marq -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jun 28 11:44:02 2007
This archive was generated by hypermail 2.1.8 : Thu Jun 28 2007 - 11:44:18 PDT