Multisim and Ultiboard

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

debugging xspice code models

debugging xspice code models

Hi gang,

 

I am trying to model a nano-electro-mechanical device using an XSPICE c code model in Multisim.  I am limping along, as the documentation is very thin with only a couple of examples.  Through a lot of trial and error, I am starting to have some success.

 

Part of what is slowing me down is that I can't see what is going on in the inner workings of my model.  I don't seem to be able to open a file to write debug information and I can't print to the console or anything.  I have created extra ports in the model so that I can spit out various numbers as voltages to look at things like my internal forces, displacements, etc.  (I just connect a resistor to ground and probe the voltage) .

 

The problem is that sometimes when I change a supply voltage or a load resistor just a little bit, the entire simulation output turns to NaNs and I have no way to set breakpoints and look at internal variables or even print messages.

 

I'm hoping someone out there has some more experience with this knows some tricks that I haven't figured out yet.  I have found the quite thin repository of old documentation at Georgia Tech, but does someone know some place to go for better documentation, examples, and tips?

 

Thanks,

Dave

0 Kudos
Message 1 of 8
(3,148 Views)

Re: debugging xspice code models

Hi Dave,

 

You are definitely touching the less traveled areas of Multisim (in fact, we didn't know if anyone actually use the code modeling). That you are using it is very interesting to me. I'll also pass on some tips about the way SPICE works. Forgive me if you already know these things

 

Code modeling is of course a way of extending the simulator by creating new primitive types. The advantages of code modeling are you can create models that you would be unable to create using other primitives, and you may get improved performance. The main disadvantage is they are difficult to create and difficult to debug. While not to discourage you from code modeling, I want to point out that Multsim supports behavioural modeling in many standard SPICE models. You can use this to create very complicated models without resorting to code modeling. The Multisim SPICE Reference section of the User Guide gives lots of details (in particular, sections Mathematical Expressions and Arbitrary Source). The other thing is wires in Multisim do not need to represent electrical signals. As far as the simulator is concerned, these are just numerical values which only become voltages/currents when they are displayed in the GUI. You can use wires to represent other concepts, such as torque and angular velocity, pressure and flow rate, etc. You might be able to use this to represent the mechanical aspects of your system. That said, I'll move on to code modeling.

 

I think you've already figured this out, but Multisim's simulator is based on XSPICE, so Georgia Tech's documentation is generally relevant, and is the best documentation available.

 

For debugging, you can create a file using code modeling that will output the inner workings of your model, and with some trickery, you can probably get a lot more information if you need. I modified the GAINTEST example to show you how you can create a file to output from your code model:

 

void cm_gaintest(ARGS)   /* structure holding parms, inputs, outputs, etc.     */
{
    Mif_Complex_t ac_gain;
    FILE * pFile;

    if(ANALYSIS != MIF_AC) {
        OUTPUT(out) = PARAM(out_offset) + PARAM(gain) *
                         ( INPUT(in) + PARAM(in_offset));
        PARTIAL(out,in) = PARAM(gain);
    }
    else {
        ac_gain.real = PARAM(gain);
        ac_gain.imag= 0.0;
        AC_GAIN(out,in) = ac_gain;
    }

   
    pFile = fopen("C:\\temp.dat", "a");
    if (pFile != NULL)
    {
            fprintf(pFile, "1\n");
            fclose(pFile);
    }
   
}

 

As you can see at the end, I'm simply writing a 1 to the file everytime the code model is evaluated, but you can of course write anything here. This isn't the most efficient way since the file must be opened repeatedly, but this will ensure that the file is correctly closed. The code also always appends to the file, so you will need to remove the file everytime you simulate to avoid confusing information, or add code to check if the file exists. I do have a couple of tips that I'll pass on as things that caught me when I was testing this.

 

  1. The code model tools except strict ANSI C. This means all variables must be defined at the beginning of the function
  2. A bug in your code model can crash Multisim. Make sure you save your work before testing the code model!

Also remember that SPICE will evaluate the model multiple times, without moving forward. I did a DC operating point of a very simple circuit containing this code model and there were 23 points. You'll probably want to add time stamps (use the TIME macro).

 

As for trickery, code modeling uses "macros" to give easy access to some of the C data structures. I case you haven't found it, they are documented on page 32 of the XSPICE Interface Design Document. You can use these for example to get the current time, which will allow you to identify whether the simulator is trying to converge at a particular time step, has moved forward, or even move backward

 

Lastly, as I said, this is the first I've heard of someone using the code model interface in Multisim. You mention that you've gotten it to work through trial and error. I would be interested to know some of the problems you encountered so that we can make it easier for other users (and maybe even you). I would also be very interested in finding out more of your application because this is the first I've heard of someone trying to model NEMS/MEMS in Multisim.

Garret
Senior Software Developer
National Instruments
Circuit Design Community and Blog

If someone helped you, let them know. Mark as solved or give a kudo. Smiley Happy
Message 2 of 8
(3,119 Views)

Re: debugging xspice code models

Garret,

 

Thanks for your response.  Seeing that you had success opening a file made me dig a little deeper and I found out that my problem was a permissions problem with Windows 7 where I couldn't write the C: drive at the root level.  I can now open a file and write debug information which will make a huge difference.

 

As for using code modeling, I was definitely starting to get the impression that I am pretty lonely out here.  I can only find a few spice packages that claim to support it and Multisim was the only one I could find that at least had a step by step example of how to build a model and get it into a schematic.

 

My model started as a c code subroutine called by my own simulation engine.  It has some pretty complicated surface integrals and non-linear equations involving things like feild emmission, tunnelling, van der waals forces, etc.  I am ready to start wrapping a lot more circuit elements around it including op-amp models, and my sim engine isn't going to cut it.  I thought it would be great to just be able to call my model from spice, and so here we are.

 

I was aware that the model would be called multiple times for time steps that would not be kept (pretty comon for adaptive time stepping methods), but cm_analog_integrate() seems to take care of this.  I created a test variable that always just integrates 1.0, and it is always exactly equal to the simulation time even when the time step is changing a lot.

 

The biggest problem I have had was that during the DC analysis, spice would sometimes call my model with a zero on one of the inputs (it was strangely unpredictable when it would do it).  Of course, buried very deeply, I had a division by this variable.  When this happened the entire simulation output would come out as quiet NaNs.  The transient analysis would keep running, just contantly turning out NaNs.  This was really hard to find without a debugger.

 

Another problem I had involved getting the pins to map to the symbol correctly.  I have a few differential bidirectional ports.  It took me a little while to figure out that these automatically built as pin pairs and that I did not have to specify both pins in the interface file.  But it really got messy when I tried to mix single ended ports with differential ports, and I could never get that to work.  So now I just stick to differential pairs for everything and that looks like it is working.

 

I am eventually going to move on to having multiple instances of the  model in the schematic and I am a little worried about how well that will work, but we'll see.

 

By the way, for anyone else finding this thread, I have used a package called Powersim in the past that made it quite easy to drop a DLL block in the schematic and call C code.  I have used it extensively to simulate power electronics controllers, but it does not have bidirectional ports and is not a true spice package, so it wasn't quite what I needed this time. 

 

I'm a little suprised that there aren't more people using this powerful method of simulating new types of devices.  The Georgia Tech documents are really old and aren't even searchable, so I guess it has never quite caught on.

 

Anyway, my model is working at the moment, and thanks again for the response.

 

Dave

 

 

 

 

 

0 Kudos
Message 3 of 8
(3,086 Views)

Re: debugging xspice code models

Dave,

 

I figured the core of the problem was a divide-by-zero or related problem.

 

Without the actual model, I can only use psychic degugging, but I can guess why sometimes you are seeing inputs at 0. Multisim will attempt to get DC convergence two different 'advanced' approaches: GMIN stepping and source stepping. What is probably happening is the GMIN failed, and it was trying source stepping. You can see if this is happening by examining the simulation log (Simulate > Simulation Error Log/Audit Trail). Once this is visible, look for the analysis (Operation performed > Output from analysis).  Near the top I think you will find a line something like GMIN stepping failed, followed by source stepping started.

 

Using multiple instances of the model in your schematic should work without problem, unless you are using static variables to store information between iterations.

 

Thanks for describing some of the problems you encountered. I will create some feature requests to see how we can improve this process.

 

Good luck!

Garret
Senior Software Developer
National Instruments
Circuit Design Community and Blog

If someone helped you, let them know. Mark as solved or give a kudo. Smiley Happy
0 Kudos
Message 4 of 8
(3,082 Views)

Re: debugging xspice code models

H,

       Even I have started writing code models. But I'm using ngspice simulator. May be we can discuss and share our knowledge 

 

-With hopes

GTRam 

 

0 Kudos
Message 5 of 8
(3,055 Views)

Re: debugging xspice code models

I have written lots of code models in ngspice (64bit) and am pleasantly surprised Multisim appears to support XSPICE and 3f5.

 

  • Can I depend on 'standard' behavior or has the interface been adapted by NI?
  • Have any of the XSPICE bugs been fixed in Multisim?
  • Can multisim be used directly from the command line (not connected to LabView), or is there a C API to at least emulate command line functionality?
  •  Is the control language of SPICE 3f5 fully supported?

-marcel

 

0 Kudos
Message 6 of 8
(2,059 Views)

Re: debugging xspice code models

Hi mhx_at_ni:

 

Multisim is based on XSPICE; however, over it has been modified and improved over many years. You can expect Multisim to be similar to XSPICE, but not identical.

 

Many XSPICE bugs have been fixed in Multisim, although I don't have a complete list of them.

 

There are a few ways you can interact with Multisim other than through the main user interface:

    1. The XSPICE command line interface (Simulation > XSPICE Command Line Interface). This gives you the ability to type in commands for the simulator. Very few if (any people) regularly use this.
    2. The COM interface. Multisim has a COM API to do some manipulation of schematics and simulate. The LabVIEW interface is just a wrapper around this COM interface. You can access the COM API directly. From the COM API, you have 2 choices.
      • Simulate an existing Multisim schematic (transient and AC)
      • Simulate using XSPICE commands (in the Multisim help, search for DoCommandLine)

Multisim uses its own control language (derived from NUTMEG). It is similar but not identical to SPICE 3f5. If you use the XSPICE command line interface or simulate using XSPICE commands through the COM API, you will need to use this command language. Unfortunately, it is undocumented. You can, however, use Multisim to determine the commands and syntax to send.

 

Each of the analyses (Simulate > Analyses) shows the commands that are sent to the simulator. You can combine these with the NUTMEG documentation to perform command line simulations. It will require some trial and error, but I have successfully in the past used this information to perform simulations.

 

CommandLine.PNG

 

Lastly, I should add that not all versions of Multisim support these features. You need either Multisim Power Pro or Multisim Educational to access the command line (there are 30 day trials if you want to test these out).

 

If you find these command line interfaces work for you, I would be interested in understanding how you are using Multisim. If it doesn't, I'd be equally interested in understanding why.

 

I hope this helps.

 

Garret
Senior Software Developer
National Instruments
Circuit Design Community and Blog

If someone helped you, let them know. Mark as solved or give a kudo. Smiley Happy
Message 7 of 8
(2,019 Views)

Re: debugging xspice code models

Hi Garret,

 

[..]

 

> Many XSPICE bugs have been fixed in Multisim, although I don't have a complete list of them.

 

It would be nice to feed the fixes back to the XSPICE maintainers (ngspice project?). In the end everybody would benefit.

 

[..]

 

> 1 The XSPICE command line interface (Simulation > XSPICE Command

>    Line Interface). This gives you the ability to type in commands for the simulator.

>    Very few if (any people) regularly use this.

 

That's me and my company, then :-)

 

But this CL is not from the Windows console commandline, I guess, but from a menu command once the Multisim has started. It is no good for IPC.

 

> 2 The COM interface. Multisim has a COM API to do some manipulation of

>    schematics and simulate. The LabVIEW interface is just a wrapper around

>    this COM interface. You can access the COM API directly.

 

A horrible Windows-only technique that I have been able to avoid for 25 years :-)

I guess I will need to write a C console program to wrap Multisim's COM, then.

 

I want to evaluate Multisim as an alternative for LTSPICE and NGSPICE as used

in a company-internal toolset.

 

Thank you for the detailed reply, it is very helpful and will save a lot of time.

 

 

0 Kudos
Message 8 of 8
(2,001 Views)