How to use ADE assembler to annotate DC voltages

Dear Pecman,

I think the issue you are experiencing might be due to the fact that you have run multiple corners in Assembler. Hence, the reason the Assembler menu items "DC voltage and DC operating point" are greyed out is that there may be multiple DC voltages and DC operating points and it cannot annotate multiple values on the schematic.

If you right click on any of the individual waveforms for any of your corners on the Results tab, you will find a item "Open Debug Environment" (see attached). Click on that option and it will bring up an Assembler ADE-L like design environment for that corner (only). The variable values shown in its Variables panel will correspond to the corner values that you selected. From that GUI, you can directly choose to annotate your schematic (see second attachment). In the example I show, I ran a set of transient analyses - so only those results are available. If I ran a set of DC analyses, DC results will be accessible.

I hope this works for you and accomplishes what you want!

Shawn

I did not run multiple corners. But the this works for me.

Thanks a lot!!!

Dear Pecman,

Pecman said:

I did not run multiple corners.

I'm just happy to read it provides the information you need - thank you for letting us know!

Shawn

You really shouldn't have to open the debug environment. You should be able to annotate the results using the context menu (right mouse button menu typically) over the output for one of the points (e.g. over the nominal column, or over the column for the corner, in the row with one of the outputs) and choose to annotate from there. If using "info balloons" for annotation, you can even annotate multiple corners at once, and as you hover over devices, it will show an info balloon with the operating point values for that device from the corners you've chosen.

If I'd been working today/tomorrow, I'd have captured a screen grab to show you what i meant, but hopefully this is clear enough.

Regards,

Andrew.

Thanks, Andrew.

It seems that I can right click in the schematic -> Annotations -> DC Voltages. I am not sure if it is what you mean. But it works too.

Dear Andrew and Pecman,

Thank you, Andrew, as always, for your insight!

i believe Andrew is suggesting to enable Info balloons as shown in the following Virtuoso menu item. Hovering over a trace will show the simulation data in a small window (see second attachment). In my case, I only have transient data and hence waveforms are displayed.

I hope this helps!

Shawn

Wawoo! 

That is pretty cool!

This is a very cool feature. But it would seem that this could be very memory(RAM) intensive. Any precautions to take while using it? Does it work with post layout simulations too? Is there a way to enable it based on netlist hierarchy?

Also, very curious to know. It this all written in Skill? Or C?

I'm not sure why you think it should be particularly memory intensive. The waveform thumbnails are turned into an image after reading the waveform data. Yes, it works with post-layout simulation (not quite sure what aspect of post-layout simulation you wouldn't be sure about (I don't believe out-of-context waveform thumbnails work from a quick check - so if you've simulated an extracted view, and descended into the corresponding original schematic, the balloons don't work; you can however use direct plot in that case). I'm not sure what the question about "enable it based on netlist hierarchy" means? Why would you want to do that? It's based on the saved waveform data, so if you've saved the waveforms, you can plot the thumbnails.

It's written in C++ (there may be some layers in SKILL, but mostly it will be in C++)

Andrew

It just seemed like a lot of data to retrieve given the ability to do it by hovering over nodes. A user could very quickly move over a lot of nodes. I assumed(incorrectly) that all this data would have to be in the RAM for a decent user experience. But it seems like the data is retrieved from the hard drive as and when required.

The netlist hierarchy question was also based on my above assumption.