Telling the calculator where the data is.

[Svenn Are Bjerkem]

Hi,

have been experimenting a bit with the calculator outside of analog
design environment and find that I can probe nets in a schematic that is
open or even a layout with the vt button. If I enter the design from the
top-level, the path that I get in the calculator window is correct, but
when I press the plot button, I get the error message that calculator
cannot find the data.

I have been simulating on the command line and the data are available in
a psf directory. I can go into the results browser and select the
simulated data. The calculator is then filled with the getData( "..."
?result "..." ?resultDir "...") function and plot work. If I try to use
the vt button in the calculator to probe in a schematic I get the fail
message:
*WARNING* data directory should be a string or symbol, setting to "."
*Warning* Wave2 is not a waveform object that can be displayed ....

I imagine that if I could set the data directory on the CIW command
line, then the calculator would be able to concatenate the resultDir to
the selected net hierarchy and I did not need to start ADE. Reason is
that I have automated my simulation on the command line, but in an
extracted view there are so many changes in net naming so it is quite
difficult to probe the correct node for plotting.

Kind regards,
--
Svenn

 

[Svenn Are Bjerkem]

Hi,
I have been reading a bit of documentation and insert some comments.

Svenn Are Bjerkem wrote:

have been experimenting a bit with the calculator outside of analog
design environment and find that I can probe nets in a schematic that is
open or even a layout with the vt button. If I enter the design from the
top-level, the path that I get in the calculator window is correct, but
when I press the plot button, I get the error message that calculator
cannot find the data.

In the Waveform Calculator Users Guide there is a short description that
caught my interest:

<quote>
You can link data from a previous simulation to a schematic window. Then
you can probe the schematic to compare the results of the previous
simulation to current results.
</quote>

This is the functionality that I would like, and I follow the procedure
to open the browser from the browser button in the calculator, I click
the psf/Run1 with the middle mouse and select the "Select Results" entry
of the pop up menu. The CIW window now reports that "Simulation results
selected from: /home/....../sim_top"

I have been simulating on the command line and the data are available in
a psf directory. I can go into the results browser and select the
simulated data. The calculator is then filled with the getData( "..."
?result "..." ?resultDir "...") function and plot work. If I try to use
the vt button in the calculator to probe in a schematic I get the fail
message:
*WARNING* data directory should be a string or symbol, setting to "."
*Warning* Wave2 is not a waveform object that can be displayed ....

I don't get the first WARNING any longer, but I still get the second.
CIW claims the wave to not be a valid waveform object data, and refuse
to plot it, so there is still a missing link out there somewhere.

--
Svenn

 

[Svenn Are Bjerkem]

Even more experimenting later:
I created a very simple design inside the ADE and netlisted and
simulated it. the openResults and outputs showed / as hierarchical
divider. I then copied the whole stuff somewhere on my disk and tried
again from that location with a new openResult and I still had the /
divider.

Then I created a parallel tree and started the simulation from the
command line. I now had . as hierarchical divider. I used the exact same
input file on the command line as in ADE, but still . instead of /.

I experimented with the working design and found that if I changed the
name of the netlist directory from 'netlist' to 'garble' I got .'s
instead of /'s in my working tree also. It seems that ocean do take some
external things into consideration when deciding what letter to use for
division of hierarchy.

I really don't understand how ocean manage to see the difference on two
equal outputs.

--
Svenn

 

[Marc Heise]

Hi Svenn,

I will interrupt your conversation with yourself and try to help.
This might help:

You can set subcktprobelvl to a value at least as high as the lowest
level of hierarchy you are interested. This will cause the names of all the
nodes to be copied to the "/" delimiter format. You will still see nodes
using >the "." format but they will also be accessible with the "/" delimiter,

except >for nodes inside any inline subcircuits. At this time these nodes must
be >accessed using the "." delimiter.

In the .cdsenv you can set:

spectre.outputs subcktprobelvl string "7"

Hope that helps,
Marc

Svenn Are Bjerkem wrote:

A bit experimenting with datasets on the CIW command line show me that I
have wrong hierarchy delimiters in my current datasets. The command line
simulation have . as hierarchy delimiter, but the data that calculator
wants to see use the / as a delimiter. I see this with the openResults,
selectResults and outputs ocean commands.

Somehow I need to tell my simulator that I need the / instead of the .

 

[Andrew Beckett]

Marc, Svenn,

I hate to contradict a colleague, but subcktprobelvl has got nothing to do
with this. That inserts current probes at the terminal of each instance to
allow you to measure currents flowing into pins on each block.

The hierarchy delimiter is governed by the presence of the map/amap
directories. The idea is that any name in OCEAN which is of the form
"/I1/I2/M0" is a _schematic_ name (i.e. any name which begins with a /).
whereas "I1.I2.M0" is using the spectre hierarchy delimiter, and hence is
referring to the _netlist_ name. Sometimes due to mapping, they are not the
same.

You can always use the simulator names, but you can't use the schematic names
unless the netlist mapping information is present alongside the netlist. In
other words, you need a fair chunk of the netlisting stuff that ADE (or OCEAN)
sticks out to be present alongside the netlist.

To your original question, I just did the following:

1. Start icms
2. Open a schematic I've previously simulated. Do _not_ start ADE
3. Type:
openResults("~/simulation/cellName/spectre/schematic/psf")
4. Tools->Analog Environment->Calculator (in CIW)
5. Hit VT button and probe on schematic - all works perfectly.

Best Regards,

Andrew.

On Wed, 02 Feb 2005 15:14:52 +0100, Marc Heise <mheise@nOsPaM.iNfO> wrote:

Hi Svenn,

I will interrupt your conversation with yourself and try to help.
This might help:

You can set subcktprobelvl to a value at least as high as the lowest
level of hierarchy you are interested. This will cause the names of all the
nodes to be copied to the "/" delimiter format. You will still see nodes
using >the "." format but they will also be accessible with the "/" delimiter,
except >for nodes inside any inline subcircuits. At this time these nodes must
be >accessed using the "." delimiter.

In the .cdsenv you can set:

spectre.outputs subcktprobelvl string "7"

Hope that helps,
Marc

Svenn Are Bjerkem wrote:
A bit experimenting with datasets on the CIW command line show me that I
have wrong hierarchy delimiters in my current datasets. The command line
simulation have . as hierarchy delimiter, but the data that calculator
wants to see use the / as a delimiter. I see this with the openResults,
selectResults and outputs ocean commands.

Somehow I need to tell my simulator that I need the / instead of the .

 

[Svenn Are Bjerkem]

Andrew Beckett wrote:

You can always use the simulator names, but you can't use the schematic names
unless the netlist mapping information is present alongside the netlist. In
other words, you need a fair chunk of the netlisting stuff that ADE (or OCEAN)
sticks out to be present alongside the netlist.

This mapping stuff is then located *in* a file or is it depending on the
*prescense* of a file or directory?

To your original question, I just did the following:

1. Start icms
2. Open a schematic I've previously simulated. Do _not_ start ADE
3. Type:
openResults("~/simulation/cellName/spectre/schematic/psf")
4. Tools->Analog Environment->Calculator (in CIW)
5. Hit VT button and probe on schematic - all works perfectly.

This works in a design that I have once created with ADE with spectre. I
now realize that I have forgotten that I am using the cds integration
for out in-house simulator. I would, of course, expect this integration
to behave differently than the spectre integration so I did an experiment:
I took the ADE created input.scs and copied it into another directory
with all the rest of the ADE stuff missing. I run spectre input.scs and
got a input.raw directory with the simulation data.
1. openResults("./cmdline/spectre/schematic/netlist/input.raw")
2. start calculator
3. Hit VT, select net
4. Didn't work because net was not a wave object.

I then went into the ADE created project and started the simulator on
the command line. This run also created an input.raw directory.
1. openResults("./aartist/spectre/schematic/netlist/input.raw")
2. start calculator
3. Hit VT, select net
4. This did work.

Now I am confused, but I am slowly starting to realize that ocean and
the calculator are depending on the prescense of extra data in the
simulation directory. As I am also using a different simulator than the
spectre one, I have to expect that our integration is working
differently than the cds one.

You may ask why I would want to simulate outside of ADE at all. It is
quite easy to answer: The in-house simulator has some extra features
that can only be controlled from the command-line. These can normally be
included with the external definition files in the Setup menu of ADE,
but it is quite a lot of work to set up a testbench, and I have to keep
an open editor on that definition file.

Kind regards
--
Svenn

 

[Andrew Beckett]

Svenn,

On Mon, 07 Feb 2005 16:22:17 +0100, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:

Andrew Beckett wrote:
The hierarchy delimiter is governed by the presence of the map/amap
directories. The idea is that any name in OCEAN which is of the form
"/I1/I2/M0" is a _schematic_ name (i.e. any name which begins with a /).
whereas "I1.I2.M0" is using the spectre hierarchy delimiter, and hence is
referring to the _netlist_ name. Sometimes due to mapping, they are not the
same.

Does some of the mapping get stored inside a cadence database or are all
information needed to map inside the schematic/netlist directory? I am
seeing some problem with probing extracted views, specially rc-extracted
where assura rcx add extra nodes for serial resistances.

All the mapping information is put in the map/amap directories in the netlist
directory.

That said, there's some additional magic involved somewhere to allow you to do
out-of-context probing (e.g. probing in the schematic, when netlisting the
av_extracted) - I'm not entirely sure where everything is stored for that.

It doesn't sounds as if you're doing that in your case, so I'd expect the
map/amap dirs would be sufficient.

Note, the contents of these directories is not public - i.e. it is expected to
be generated by Cadence functions, and read by Cadence functions (and it has
been known to change in different releases - which of course doesn't cause
any problems if it is read and written by the same tool). Put another way, you
may be able to figure out the structure/contents of map/amap dirs, but don't
rely on it never changing.

Shouldn't be an issue if the netlist is generated via a netlister which is
part of an ADE integration.

Regards,

Andrew.

 

[Svenn Are Bjerkem]

Hi Andrew,

Andrew Beckett wrote:

be generated by Cadence functions, and read by Cadence functions (and it has
been known to change in different releases - which of course doesn't cause
any problems if it is read and written by the same tool). Put another way, you
may be able to figure out the structure/contents of map/amap dirs, but don't
rely on it never changing.

Shouldn't be an issue if the netlist is generated via a netlister which is
part of an ADE integration.

Thanks for this information. Based on what you say, I think that what I
thought of doing is pretty much a waste of time. I was originally
thinking of generating the netlist *once* with the ADE integration, and
then later replace data inside the netlist directory in order to be able
to simulate on the command line but still have the possibility to probe
signal names with the calculator in the schematics.

Now I have discovered that extracted views introduce new nodes in my
netlist that would have to be "backannotated" into the map/amap
directories for composer to know the names. This is an impossible task.
It is my experience that running a project from within ADE is not a
guarantee that I can probe nets after an rc-extracted. Assura tend to do
what she wants with netnames that she is extracting.

I think I'll leave this trail for a while and maybe come back when I
have more experience with extracted views.
--
Svenn

 

[Andrew Beckett]

On Tue, 08 Feb 2005 08:39:16 +0100, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:

Hi Andrew,

Andrew Beckett wrote:
be generated by Cadence functions, and read by Cadence functions (and it has
been known to change in different releases - which of course doesn't cause
any problems if it is read and written by the same tool). Put another way, you
may be able to figure out the structure/contents of map/amap dirs, but don't
rely on it never changing.

Shouldn't be an issue if the netlist is generated via a netlister which is
part of an ADE integration.

Thanks for this information. Based on what you say, I think that what I
thought of doing is pretty much a waste of time. I was originally
thinking of generating the netlist *once* with the ADE integration, and
then later replace data inside the netlist directory in order to be able
to simulate on the command line but still have the possibility to probe
signal names with the calculator in the schematics.

Now I have discovered that extracted views introduce new nodes in my
netlist that would have to be "backannotated" into the map/amap
directories for composer to know the names. This is an impossible task.
It is my experience that running a project from within ADE is not a
guarantee that I can probe nets after an rc-extracted. Assura tend to do
what she wants with netnames that she is extracting.

I think I'll leave this trail for a while and maybe come back when I
have more experience with extracted views.

Just a thought...

You could always create the netlist with:

simulator('spectre)
design("libName" "cellname" "viewname")
createNetlist(?display nil)

(this has to be done in a DFII session - i.e. icms, icfb, msfb; not the
"ocean" executable as that can't create netlists).

Or you could do your OCEAN scripts using the three-arg version of design and
then run the simulation as normal. No need to create the netlist manually in
ADE then.

Regards,

Andrew.