Verilog-A -> B model

[Kevin Cameron]

Is anybody interested in helping with a Verilog-A to B-model translator?

My Verilog-AMS parser can probably do it - general idea is to just translate Verilog-AMS to Xyce-compatible input.

Preferably that would a pluggable-parser approach that could equally well be used for odd Spice dialects, VHDL(-A), MAST,...

There are a bunch of unnecessary SPICE simulators I'd like to kill off ;-)

Kev. 

[ngw]

ADMS would be the recommended tool for this task. That said, I'm not sure what value this effort would have given that all contemporary simulators can adequately support Verilog-A translation to native low-level source.

[Murat Eskiyerli]

Although I could not possibly help with the coding effort, it could be possibly very useful.

[Kevin Cameron]

I'm not sure I would recommend ADMS for anything myself, it was all a big hack from the get-go. I'm more interested in using this kind of stuff to get derivatives directly -

https://ginac.de/

- i.e. translate Verilog-A fairly directly to C++ and let Ginac do the hard work.

The tricky piece with Verilog-A is the conditional stuff and the switch-branches, but a lot of that can be translated into something more friendly.

[Kevin Cameron]

This mostly about finding a starting point where we can do minimal work to get something useful, if you have models you would like to use but are not currently supported that would be helpful.

The pluggable-parser idea would support parsers that just do minor tweaks to existing netlists for (say) LtSpice, SIMPLIS etc., and could just be in Perl/Python - basically like the C preprocessor. Goal is to have it as something people can hack to their own needs and not have to rely on the Sandia team.

Can probably do Verilog to U model too.

I can do coding, but I usually don't have any good design data to work with.

[Justin Fisher]

Hi Kev.

When you say you don't have good design data, what exactly do you need?

Justin.

[Kevin Cameron]

Real designs, large stuff like complete ICs and/or working IP blocks.

The main entry point for analog/mixed-signal simulation into EDA flows is supporting things like PLLs and SERDES in a largely digital design flow. Quite a lot of that is in the IP market, so I'm seeing Xyce as a way to support modeling IP and distributing it to customers.

Note: PWL based models don't necessarily have to go in the matrix, they can be handled with event-driven simulation. There's a complete lack of digital simulators that can do that and handle power and thermal issues - which is going to be more important  with 3D-IC approaches.

Unfortunately getting in there (usually) requires using the standard languages.

Kev.

[Marcel Hendrix]

On Wednesday, May 20, 2020 at 7:14:50 PM UTC+2, Kevin Cameron wrote:

[..]

Note: PWL based models don't necessarily have to go in the matrix, they can be handled with event-driven simulation.

[..]

Could you expand a little bit on that? I'd think such a model behaves like a B-source, and as such should go into the MNA generated matrices. (there could be tricky feedback from outputs to inputs).

Also, event-driven normally means setting breaks on time. Setting breaks on arbitrary variables could become hairy (my Katzen-Nelson is rather rusty). 

-marcel

 

[Kevin Cameron]

Digital models can generally be handled as something which is a state machine with a delay from the state transitions (inputs crossing thresholds) to the outputs (PWL scheduling) - nothing that needs to go in the matrix solve until you add analog circuitry to the outputs - and R/C circuits (for wiring) can be done analytically. In a parallel-processing world you want to localize the breaks if you can. Most analog simulators are essentially event-driven engines dealing with PWL signals, with the addition of model interaction which needs resolved by using a solver.

Kev.

--
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/9828cc79-946a-483c-9c0f-80658e20539fo%40googlegroups.com.

[Marcel Hendrix]

A bit late, sorry.

In power electronics circuits, simultaneous transitions will happen when the devices are made ideal

(for speed reasons). It is possible to weed out the events that are impossible by using implicit and

explicit constraints. That is where the Katzenelson algorithm comes in.

-marcel

[Kevin Cameron]

https://onlinelibrary.wiley.com/doi/abs/10.1002/j.1538-7305.1965.tb04195.x

In that vein -

https://github.com/peaclab/PACT

The guys also containerized Zyce to make it easier to deploy. 

(Came up at the DAC BOF meeting).

To view this discussion on the web visit https://groups.google.com/d/msgid/xyce-users/069dbcad-3ba0-422d-979b-8735970c0881n%40googlegroups.com.