Cross method in Ocean script

V

Verictor

Guest
Hi,

I have a testbench schematic which I have save as an Ocean script. In
the Analog Design Environment of the schematic, I configured a
transient analysis and a variable that computes the transient point of
a particular node. That worked fine in the schematic. When I ran the
Ocean script, it could simulate but also reported this:

ocean> *Error* crossMethod: can't handle crossMethod(nil 0.625 1
"rising" nil nil)

The cross method is defined as something like this in the converted
Ocean script.:
cross_point=cross(( v "NetA\\:NodeB" ?result "tran-tran" ?resultDir
"/myDir") (VAR("vdd")/2) 1 "rising nil nil)

Basically it is about the transient mid-range point. Nothing was
changed during schematic --> Ocean conversion. Is the error caused by
the cross method? Or the above "cross_point" definition needs to be
changed in the Ocean script?

Any suggestions?

Thanks
 
Hi,

I narrow down the problem to the design hierarchy: the Ocean script is
generated from the top level schematic while NetA/NodeB is indeed
existing in an extracted subcircuit (using textual netlist). Therefore,
the net names have been changed. To confirm this, if I used the pure
schematic view instead of extracted circuit, everything works fine.

So how to deal with such hierarchy after extraction?

Thanks

On Nov 20, 2:05 pm, "Verictor" <stehu...@gmail.com> wrote:
Hi,

I have a testbench schematic which I have save as an Ocean script. In
the Analog Design Environment of the schematic, I configured a
transient analysis and a variable that computes the transient point of
a particular node. That worked fine in the schematic. When I ran the
Ocean script, it could simulate but also reported this:

ocean> *Error* crossMethod: can't handle crossMethod(nil 0.625 1
"rising" nil nil)

The cross method is defined as something like this in the converted
Ocean script.:
cross_point=cross(( v "NetA\\:NodeB" ?result "tran-tran" ?resultDir
"/myDir") (VAR("vdd")/2) 1 "rising nil nil)

Basically it is about the transient mid-range point. Nothing was
changed during schematic --> Ocean conversion. Is the error caused by
the cross method? Or the above "cross_point" definition needs to be
changed in the Ocean script?

Any suggestions?

Thanks
 
I presume the name in the database is the same - perhaps just the mapping
of the name in the netlist has changed?

If so, does it work to use the DFII name rather than the netlist name?
DFII names begin with / and are then mapped to whatever they
were called in the netlist. In other words, use:
/I1/I2/netA for example.

The naming of your nets sounds a little odd - I'm wondering
what netA\\:nodeB actually means?

Regards,

Andrew.

On 20 Nov 2006 17:12:22 -0800, "Verictor" <stehuang@gmail.com> wrote:

Hi,

I narrow down the problem to the design hierarchy: the Ocean script is
generated from the top level schematic while NetA/NodeB is indeed
existing in an extracted subcircuit (using textual netlist). Therefore,
the net names have been changed. To confirm this, if I used the pure
schematic view instead of extracted circuit, everything works fine.

So how to deal with such hierarchy after extraction?

Thanks

On Nov 20, 2:05 pm, "Verictor" <stehu...@gmail.com> wrote:
Hi,

I have a testbench schematic which I have save as an Ocean script. In
the Analog Design Environment of the schematic, I configured a
transient analysis and a variable that computes the transient point of
a particular node. That worked fine in the schematic. When I ran the
Ocean script, it could simulate but also reported this:

ocean> *Error* crossMethod: can't handle crossMethod(nil 0.625 1
"rising" nil nil)

The cross method is defined as something like this in the converted
Ocean script.:
cross_point=cross(( v "NetA\\:NodeB" ?result "tran-tran" ?resultDir
"/myDir") (VAR("vdd")/2) 1 "rising nil nil)

Basically it is about the transient mid-range point. Nothing was
changed during schematic --> Ocean conversion. Is the error caused by
the cross method? Or the above "cross_point" definition needs to be
changed in the Ocean script?

Any suggestions?

Thanks
--
Andrew Beckett
Principal European Technology Leader
Cadence Design Systems, UK.
 

Welcome to EDABoard.com

Sponsor

Back
Top