ADE-XL and matlab debugging

Hi Dan,

The most useful way to debug things is to enter:

axlDebugFlag=t

in the CIW before starting ADE XL and running the simulation. In addition to some other verbiage, it also tells you about the interaction between ADE XL and Matlab. It's invaluable for debugging problems with this interface.

Some answers to your questions:

1. I never use addpath in my scripts - all I do is setenv MATLABPATH to `cds_root spectre`/tools/spectre/matlab/64bit (I only use 64-bit Matlab, as that's the only supported version these days, if I remember rightly)
   1. No, matlab outputs are only supported in ADE XL, not ADE L
   2. I think this is covered in the MMSIM documentation for the Matlab toolbox. Ah, I see - it doesn't mention the 64bit part... (looks like it hasn't been updated for a while)
2. That's odd. It works for me. I don't think it can be $DISPLAY, since that should be set before virtuoso runs. Maybe something in your environment is not getting the path set correctly, but that seems unlikely.
3. ADE XL stuff:
   
   1. Note that the useNMPForMapping will only help for new ADE XL views. Existing ADE XL views don't get influenced by this variable. However, the case where it causes problems is where you have a ":" in your testname (which is unfortunately the default in ADE XL). You can solve that by just renaming the test (click on the name twice and rename it )
   2. Hopefully the debug flag will get to the bottom of this. All ADE XL does is launch "axlMatlab" (which is in <ICInstDir>/tools/dfII/bin and pass envGetVal("adexl.simulation" "matlabRunArguments") to it (which defaults to "-nodesktop -nosplash")
   3. The debug flag will help here
   4. The point in a should help here. The other thing you have to be careful about is having an OCEAN script with the same name in the working directory. I believe that Matlab always looks in the working directory first for a script regardless of the path (we do an addpath to add the scripts directory to the path). In general I'd probably leave the copyMeasurementScripts at its default value (t).
   5. No, the script can only output a single scalar number. You can get it to dump data somewhere or even output a plot, but outputting a waveform is not possible. There are enhancement requests related to this if I remember rightly.

(note my letters a-e correspond to your sub-numbers 1-5 etc).

Once you have got this working, it does work fairly smoothly - but the lack of good error reporting is one of the things that tends to make this a challenge to set up.

Hope that helps!

Regards,

Andrew.

Renaming the test got the matlab script to run. I couldn't see that axlDebugFlag=t (ran first thing after launching virtuoso) did anything at all. I didn't see any extra output in my CIW window when i then launched ADE-XL and ran a sim. Is there some place I should look for the debug output? One thing I have noticed is that if there is a bug in the matlab script then I don't see any sort of log where the error is listed. It is too bad that the copyMeasurementScripts nil doesn't seem to work. I'm really not a fan of having my matlab script embedded inside of the adexl view. I tried setting the matlabRunArguments to "" in the hopes that I would get an interactive matlab session and be able to more effectively debug my matlab script. As it stands, any sort of matlab error and I get nothing back to look and no error message at all.

Hi Dan,

Can you check Options->Log Filter in the CIW - do you have "Standard message output" checked? If not, then it's not going to appear. Other than that, you should see "DAVINCI" messages in the CIW.

If there's a bug in the matlab script, you should see some info about it in the CIW if you have the debug flag turned on - so hopefully you typed it correctly.

You don't have to put the script inside the ADE XL view - that was only a suggestion. It should work fine to set copyMeasurementScripts to nil - I was just saying that you don't have to, and my preference is to manage all the files related to the ADE XL view together (useful if using design management, as the whole set of data gets managed together then). If you don't want that, that's OK too.

I wouldn't in general mess with the matlabRunArguments because if you allow it to bring up the GUI, ADE XL will not be able to synchronize with it because it is trying to look for information on the matlab standard output, and if running with the matlab GUI, it doesn't appear on standard output and that won't work...

Regards,

Andrew.

I double checked the log filter and "Standard message output" was already turned on. I didn't see any DAVINCI messages. I can't see that setting copyMeasurementScripts to nil does anything. I put it in my .cdsinit and restarted virtuoso. I entered /home/dan/myscript.m and then as soon as I run the sim, it copies the script over and changes the outputs setup.

Dan,

For me, axlDebugFlag works, but looking again at the code, it probably should have been _axlDebugFlag=t (with a leading underscore). I can't test the matlab interface as I'm not using my work computer (where I have access to matlab), but I'm pretty sure that should do it. It's more verbose however and prints far more other things.

You're right though - copyMeasurementScripts set to nil doesn't seem to be working. I just tried it. I filed CCR 1422706 to get this fixed. It appears initially that the path is preserved, but as soon as it saves the adexl view (either via save or by running a sim), it changes it to be in the adexl view.

Regards,

Andrew.

Adding the "_" in front, so using _axlDebugFlag=t, did turn on a bunch of DAVINCI DEBUG output.  This is certainly helpful although I can think of a few relatively simple enhancements which would all be quite useful and make this whole flow much more user friendly.

- A log file dedicated to the matlab portion would be most useful.  While I can now see errors in the matlab script (I introduced one to see how it showed up) in the debug output, it is a bit hard to read.  I'm guessing the same applies to ocean measures.

- It would be very useful to have a "debug the matlab measure" mode where it would launch the script but then instead of exiting, leave a matlab prompt.  That would make it much simpler to work out any kinks in the script..  My short term workaround is to use exist() to see if  axlCurrentResultsPath is defined and if not, use a hard coded path.  Then I can use the same script standalone for debugging and as an output (except the copying to ADE-XL view is unfriendly towards this.

- Allowing matlab (and also ocean) measures in ADE-L (not ADE-XL) would be very helpful.

- The ability to return a waveform instead of only a scalar would be useful.

- The ability to return multiple outputs from the same script would be quite usefull

- It would be nice if I could use octave as well as matlab

Thanks for the help

-Dan

Hi Dan,

I would suggest that some of these you contact customer support and request them as enhancements. I can give you some references for some of them that I think would be worth following up on, and I'll indicate those that are unlikely to have anything done on:

1. Log file - excellent idea. Debugging right now is far harder than it should be.
2. This is probably not that straightforward when you have multiple tests or multiple outputs (or sweeps, corners etc) as all will go through the same matlab; matlab doesn't actually exit. I can see why you want it though...
3. I think it's highly unlikely Matlab or Ocean script output support will be added to ADE L
4. Waveform output is an existing enhancement CCR (filed by me): 989142
5. Multiple outputs - good idea. There are a number of existing requests for this - the master CCR is 1034185
6. Octave support. There are CCRs for this, but there is little prospect of this. We have looked into it in some detail, but the Octave license  makes this a non-starter for a commercial tool (I won't go into all the details here - but we have looked into this in some depth and tried to find solutions to it). I can entirely see why you'd want this (and some of the CCRs on this are from me), but this is very unlikely to be possible.

So for 1, 4 and 5 above, I'd suggest contacting support and then either new CCRs or duplicates can be filed. Maybe 2 as well, although that's not so obvious how it could be done.

Kind Regards,

Andrew.

Hey Dan:

I have also been using the matlab output scripts. I found it useful to have MATLAB create its own log using the diary command which can capture MATLAB outputs and errors to a file.

You can also make it easier to debug by having the MATLAB script open an interactive session and display the normal matlab desktop when the script is ran by using the "desktop" command within your script.  Note that it can take a little while to open the matlab desktop and the script is run for each corner or each monte carlo sim ran.  The "workspace" command can also be useful for viewing variables as they change.

-Curtis

Andrew:

I thought I had this matlab script method basically working a couple of months ago. However now that I have come back to it somehow a colon keeps popping up in my path even though I don't have a colon in my test name in adexl.

Here is the path it moves the script to:
/prj/sky78140_mk5325asm_CR/work_libs/mayberc/cds/design/SW_CTRL_mk5325a_01_power_TB/adexl/test_states/sky78140_mk5325asm_CR_mayberc/SW_CTRL_mk5325a_01_power_TB/spectre/Vreg2p5v_stb_cap_Vreg2p5v_stb:1_state_capTest2p5.15/outputsScriptsDir

The test is named Vreg2p5v_stb_cap and it seems that it now appends the ":1_state_capTest2p5.15" which includes the run name I used "capTest2p5.15" and unfortunately a colon.

Any way I can get around this to get it working again?

-Curtis

I reran my old testbench where I had it working and it specified the following as the run directory:

/prj/sky78140_mk5325asm_CR/work_libs/mayberc/cds/design/POR_VIO_TB/adexl/test_states/sky78140_mk5325asm_CR_mayberc/POR_VIO_TB/spectre/POR_VIO_TB_Transient_Vlo_active/outputsScriptsDir/plotPOR.m

You can see it used "POR_VIO_TB_Transient_Vlo_active" rather than "Vreg2p5v_stb_cap_Vreg2p5v_stb:1_state_capTest2p5.15"

The old adexl state still runs correctly.