EKV2.6

[Георгий Яшин]

Hello!

Is there any way to use older version of EKV model, EKV2.6?

Thank you in advance!

[xyce-users]

It is not well documented because we haven't got good verification/validation tests for it, but the EKV 2.6 model is already in XyceNF (the version you can get in binary form from our web site) as the level 260 MOSFET.  Simply provide an NMOS or PMOS model card with LEVEL=260 and you should be able to try it out.

Unfortunately, the EKV 2.6 model we obtained did not come with a validation test suite, so we can only hope that it is imported correctly from the author's Verilog-A model file.  But it's there.

[George Yashin]

Great, thank you a lot for fast response, I will try :)

четверг, 1 сентября 2022 г. в 22:49:22 UTC+1, xyce-users:

[xyce-users]

The EKV 2.6 model in Xyce was provided to us under an NDA years ago when it was still not open sourced.  It is a slight modification of the EKV 2.6 model that has *since* been open sourced and available at https://github.com/ekv26/model.  The most important modifications are those in pull request #1 of that repository.

If you find that our XyceNF binary is not working out for you your only option would be to build the open source Xyce from our github repository in shared-library mode (not the default) and try to build a Verilog-A plugin using the instructions in our Xyce/ADMS Users Guide.  The source code from https://github.com/ekv26/model with the pull request's patch applied *should* be importable as a "YEKV_VA" device (as described in the Xyce/ADMS guide) that should at least be the same as what its authors intended should ours prove not to be.

However, you will find that the published version of EKV 2.6's verilog-a model has some odd differences from other, reverse-engineered versions you may find on the web, and therefore might not be exactly the same version that shows up in other open source simulators.  Some of those issues are reported in that model's github repository issue section.  This might lead to strange differences between results from different simulators. 

This is one of the reasons we don't actually document the fact that we have EKV 2.6 in the code.  We are not absolutely certain it's usable with any EKV model cards out in the wild.  If it breaks something, you own both pieces.

I would be delighted to hear what you find as you try out the model.

[George Yashin]

Yea, I already noticed that some parameters are missed in Github version in comparison with older one.

I have checked DC curves with LTSpice, at first glance they are identical, I will check also a AC and dynamic behaviour.

четверг, 1 сентября 2022 г. в 23:12:47 UTC+1, xyce-users:

[George Yashin]

Also, why Xyce doesn't support models from HiSIM family? It needs additional licensing?

пятница, 2 сентября 2022 г. в 23:45:09 UTC+1, George Yashin:

[xyce-users]

The HiSIM models all make use of Verilog-A features that aren't very well implemented in Xyce/ADMS.  I spent a bunch of time trying to get them to work, and I *think* we're just about there, but project priorities are such that I can spend very little time on the Xyce/ADMS system.  Furthermore, even though I think that Xyce/ADMS is just about in the right shape to support HiSIM, last time I tried there were some problems.  I believe that last time was before I fixed a major bug in Xyce/ADMS, and so I am really not sure where it stands right now.  HiSIM is definitely on the team's radar, but until I have time and funding to spend on Xyce/ADMS *OR* we get a much better replacement for Xyce/ADMS, it may not become high on our priorities until an internal user (i.e. the ones we're funded to support) absolutely requires it.

There's no licensing problem.  It's strictly an issue of how well Xyce/ADMS supports (or doesn't support) the full Verilog-A standard.

[George Yashin]

Got it thank you. Also, older versions of HiSIM availible in C code ( HiSIM2 Download Page (hiroshima-u.ac.jp)  ), but as I understand, it is difficult to implement too, because Xyce doesn't rely on Berkley SPICE3 code. But I think that Xyce uses the same MNA technics with "stamps"...

воскресенье, 4 сентября 2022 г. в 01:32:09 UTC+1, xyce-users:

[xyce-users]

Porting SPICE3F5 C code to Xyce is a major effort. Definitely not worth the trouble for very old versions of a model.  Yes, we use basically the same techniques and much of the code needs only a syntax modification, but the mathematical formulation is different enough that the vector and matrix loads are all different so one must carefully tease apart terms and do those the Xyce way.

The more likely way that HiSIM will get into Xyce is that I discover that my last iteration on Xyce/ADMS was already enough to get us over the finish line, in which case all I need is a block of time to test it out.  If that is not the case, it will likely not happen until Xyce/ADMS is replaced with a better Verilog-A compiler.  Neither is likely to happen before the next release.

[Murat H Eskiyerli]

Should we understand that there are plans to replace ADMS in Xyce?

Murat H Eskiyerli

---

From: xyce-users <xyce-...@googlegroups.com>
Sent: Sunday, September 4, 2022 1:55:40 PM
To: xyce-users <xyce-...@googlegroups.com>
Subject: [xyce-users] Re: EKV2.6

 

--
You received this message because you are subscribed to the Google Groups "xyce-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/4ac8c1ce-efc0-447b-a9d6-74298c384b24n%40googlegroups.com.

[xyce-users]

Ultimately, yes; we plan to replace ADMS.   How soon that will happen is another question and still TBD.

thanks,

Eric

[Kevin Cameron]

The models should all be dynamically (re)compiled to get the most optimal versions for the netlist in question.

Carving the ADMS stuff out in a way that it does that as a plug-in would be half way to replacing it.

AFAIK most of the commercial simulators only have built-in models and can't recompile on-the-fly to get better performance. Once you take out all the constant stuff things should go faster.

IMO, if you want the behavior of some other simulator in Xyce, you would be better off just digitally-twinning it at the block level than trying to match individual transistor models. Very few circuits use individual transistors, and PMIC (where I'm working) really doesn't need them to be super accurate (most people design with SIMPLIS).

Kev.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/9a3cab01-22c9-4e56-b84d-569f2d11601fn%40googlegroups.com.

[xyce-users]

We are aware of all these ideas.   We already support dynamic plugins from ADMS and have for a while.  Optimizing code from ADMS (or any model compiler) is something we've explored for various applications.  But it is much more likely to be addressed in the ADMS replacement.

PWL-based simulators like SIMPLIS is also something we're aware of.  But, there hasn't been any internal interest in pursuing this approach.

thanks,

Eric

[Kevin Cameron]

If ADMS is used as a plug-in in a way that it can be replaced by a different plug-in, maybe someone else would build the replacement? I assume plug-ins can be commercial/proprietary code.

Most commercial simulators (SIMPLIS, HSPICE, etc.)  are used to develop IP, making the models of the IP portable can be either using a standard language (like Verilog-AMS), or a standard simulator interface. Given the lack of Verilog-AMS support in Xyce, the latter option is probably the only choice.

Digitally twinning transistor level simulations into behavioral/block level is possibly more useful than trying to get transistor-level compatibility, since it gives you a speed-up (as well as compatibility), and can be automated for a lot of standard blocks.

I think SIMPLIS is just a SPICE simulator with table-driven device models to make it go fast. I'd like a replacement, since it only works on Windows (as does LTspice).

Kev.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/da619396-d4dd-4cc1-9ad2-6e32f25cf0d7n%40googlegroups.com.

[Renaud GILLON]

Hello Kevin,

I have read your document with interest (I did experiments in the past on using resolution functions to perform event-driven -- I mean "really" event-driven, not discrete-time as EDA vendors are suggesting to do as soon as you have dynamic components like caps and inductors -- simulations of analogue circuits in a digital simulator). 

I noted that you touch briefly on fault injection. Actually, as far as I understand, there is a serious limitation in the implementation of the standards when you try to inject open / shorts in the interconnects (modelled with resolved nets), as in most digital simulators you only have a a FORCE function that allows to set a signal to a fixed value (which corresponds essentially to a short to supply) and you don't have the possibility to play around with the lists of drivers / receivers of that signal.

Playing around with drivers / receivers lists using a new command of comparable scope to FORCE, would allow to inject opens and shorts in the interconnects efficiently (as in SPICE today) w/o having to take the burden to modify the code of the blocks being interconnected. I have discussed this idea when at my previous employer with one of the major EDA vendors, they showed some interest, however, I don't know what they've done with it since.

From my perspective, I think it would be useful to extend standards to include such functions that allow to modify drivers / receviers lists in order to inject defects in the interconnects. What do you think about this  (would it somehow fit in your initiative) ?

Regards,

Renaud

On Sat, 8 Oct 2022 at 19:26, Kevin Cameron <camer...@gmail.com> wrote:

Hi all,

For anyone that is interested, I'm writing a proposal document for how
to do mixed-type resolution in SystemVerilog-AMS. This is being driven
(partially) by people wanting to do SystemC-AMS along with SystemVerilog.

Done properly it creates a bridge point for getting in and out of an
analog simulator and opens up the opportunity to use Xyce with
SystemC-AMS which would make it an entirely open-source simulation
environment from SoC test-bench to transistors.

Let me know if you want to comment -

https://docs.google.com/document/d/1PYPo_ZAiOtVXl53TDIBxyPwWoXFiwSpSYHCl3LPexXU/edit?usp=sharing

Or just reply here.

If you are eligible for IEEE-SA participation, you can join P1800 and
help make this happen, let me know if you want to do that too.

Kev.

https://www.linkedin.com/in/kevcameron/

--
You received this message because you are subscribed to the Google Groups "xyce-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xyce-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/362edb68-9943-262d-65a4-f182b2ee7b28%40gmail.com.

--

Renaud GILLON

SYDELITY
"Scaleable Virtual Prototyping"

Mobile : +32 (0)495 27 65 65
E-mail : renaud...@sydelity.com
Web:     www.sydelity.com