simulating with ahdl code on Cadence IC 5.1.41.usr2

[Gerard Wienk]

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that has
ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/
(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/
for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-
bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-
bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[Bernd Fischer]

Hi,

This is what Andrew told me about how Verilog-A compilation was handled in DFII
in 5.1.41. I think he don't object that I post this here.

In IC5141, Verilog-A code is compiled to a shared library. It converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a CMI library
(compiled model interface).
It means that the first time you use a model it takes a little longer,
but on subsequent runs it just links in the shared library. The idea, of
course, is that the shared library should have better performance than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
<install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
<install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that has
ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[Andrew Beckett]

Further to what Bernd says (and I don't mind him posting what I've said), you
should take a look at the log files in the ahdlcmi directories that are created
- they are usually revealing as to the root cause of the problem.

Regards,

Andrew.

On Mon, 14 Nov 2005 16:04:19 +0100, Bernd Fischer
<""bernd.fischer\"@xignal-A%&HY%$v#&G=.de"> wrote:

Hi,

This is what Andrew told me about how Verilog-A compilation was handled in DFII
in 5.1.41. I think he don't object that I post this here.

In IC5141, Verilog-A code is compiled to a shared library. It converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a CMI library
(compiled model interface).
It means that the first time you use a model it takes a little longer,
but on subsequent runs it just links in the shared library. The idea, of
course, is that the shared library should have better performance than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:
Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that has
ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[Bernd Fischer]

Indeed Andrew is right, I forgot to mention ;-).

So if issue 1.) is the root cause of your problem, which I truly believe,
then you have to go to into your simulation directory
<yourCell>/spectre/schematic/netlist/ahdlcmi/<blabla>.va.ahdlcmi

You will find the 'ahdlcmi.out' file there
and in the last lines you will see
gnumake: <installDir>/tools/systemc/gcc/install/bin/gcc: Command not found
gnumake: *** [obj/Linux2.4.21-15.ELsmp+gcc/optimize/libahdlcmi.so] Error 127

Bernd

Andrew Beckett wrote:

Further to what Bernd says (and I don't mind him posting what I've said), you
should take a look at the log files in the ahdlcmi directories that are created
- they are usually revealing as to the root cause of the problem.

Regards,

Andrew.

On Mon, 14 Nov 2005 16:04:19 +0100, Bernd Fischer
""bernd.fischer\"@xignal-A%&HY%$v#&G=.de"> wrote:


Hi,

This is what Andrew told me about how Verilog-A compilation was handled in DFII
in 5.1.41. I think he don't object that I post this here.


In IC5141, Verilog-A code is compiled to a shared library. It converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a CMI library
(compiled model interface).
It means that the first time you use a model it takes a little longer,
but on subsequent runs it just links in the shared library. The idea, of
course, is that the shared library should have better performance than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that has
ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[Gerard Wienk]

Hello Bernd,

Thanks a lot.

With this new release of Cadence you can also setup a MMSIM tree(I have
version 6.0.USR1). This tree contains UltraSIM but also a version of
SPECTRE. This setup has the required directory "systemc" which the
dfII tree has not.
If you put the PATH variable to mmsim/tools/bin in front of any dfII
paths then the MMSIM version of SPECTRE will be executed and compiling
will work!

But this version of SPECTRE cannot handle the way my design kit model
libraries are provided.
Here is some output:

-> Simulating `input.scs' on icetux5 at 5:21:01 PM, Mon Nov 14, 2005.
-> Using new Spectre Parser.
-> Error found by spectre during circuit read-in.
->"/cadappl/iclibs/CMOS18/../../tools/spectre/c15/include_nominal.spectre"
->1: Spectre "include" statements are not supported in spice language
->sections. Use "simulator lang = spectre" to introduce Spectre language
->sections.
->spectre terminated prematurely due to fatal error.

This include_nominal.spectre file looks like this:

<>include "fns_global.spectre" section=nominal
<>include "process.spectre"
<>include "if_CMOS18xxxxc15.spectre"
<>include "statistics.spectre"


So I deleted the MMSIM path variable and copied the "systemc" directory
to the dfII/tools directory.
This seems to work well, it compiles libahdlcmi.so and simulates the
circuit without error messages.

For historic reasons I always used SPECTRE_DEFAULTS=-E but with
IC5.1.41usr2 this setting gives following message:
cpp:unrecognized option'-$'


What are your thoughts about all these issues?

Thanks again for putting me on the right track.

Regards,

Gerard




Bernd Fischer > wrote:

Hi,

This is what Andrew told me about how Verilog-A compilation was handled
in DFII
in 5.1.41. I think he don't object that I post this here.

In IC5141, Verilog-A code is compiled to a shared library. It
converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a CMI
library
(compiled model interface).
It means that the first time you use a model it takes a little longer,
but on subsequent runs it just links in the shared library. The idea, of
course, is that the shared library should have better performance
than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that has
ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[Bernd Fischer]

Why didn't you put just a 'simulator lang=spectre' on top of
your 'include_nominal.spectre' file as the Spectre output tells you.
Then you probably could have used MMSIM.

To have the simulators UltraSim & Spectre in a different "Stream"
is the new Release Model of Cadence. I think to use it right away is
future proof.

Also I believe in MMSIM Cadence cleaned some mess in the
Spectre Parser, I saw a similar think with inline subcircuits.

Form me the Parser is more strict now, which not means that
this has to be worse. You have the chance to get Error Messages and
correct your Model Libraries due to that.

Don't know much about SPECTRE_DEFAULTS=-E, sorry.

Bernd


Gerard Wienk wrote:

Hello Bernd,

Thanks a lot.

With this new release of Cadence you can also setup a MMSIM tree(I have
version 6.0.USR1). This tree contains UltraSIM but also a version of
SPECTRE. This setup has the required directory "systemc" which the
dfII tree has not.
If you put the PATH variable to mmsim/tools/bin in front of any dfII
paths then the MMSIM version of SPECTRE will be executed and compiling
will work!

But this version of SPECTRE cannot handle the way my design kit model
libraries are provided.
Here is some output:

-> Simulating `input.scs' on icetux5 at 5:21:01 PM, Mon Nov 14, 2005.
-> Using new Spectre Parser.
-> Error found by spectre during circuit read-in.
->"/cadappl/iclibs/CMOS18/../../tools/spectre/c15/include_nominal.spectre"
->1: Spectre "include" statements are not supported in spice language
->sections. Use "simulator lang = spectre" to introduce Spectre language
->sections.
->spectre terminated prematurely due to fatal error.

This include_nominal.spectre file looks like this:

include "fns_global.spectre" section=nominal
include "process.spectre"
include "if_CMOS18xxxxc15.spectre"
include "statistics.spectre"


So I deleted the MMSIM path variable and copied the "systemc" directory
to the dfII/tools directory.
This seems to work well, it compiles libahdlcmi.so and simulates the
circuit without error messages.

For historic reasons I always used SPECTRE_DEFAULTS=-E but with
IC5.1.41usr2 this setting gives following message:
cpp:unrecognized option'-$'


What are your thoughts about all these issues?

Thanks again for putting me on the right track.

Regards,

Gerard




Bernd Fischer > wrote:

Hi,

This is what Andrew told me about how Verilog-A compilation was
handled in DFII
in 5.1.41. I think he don't object that I post this here.

In IC5141, Verilog-A code is compiled to a shared library. It
converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a CMI
library
(compiled model interface).
It means that the first time you use a model it takes a little longer,
but on subsequent runs it just links in the shared library. The
idea, of
course, is that the shared library should have better performance
than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that
has ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[Andrew Beckett]

Hi Gerard,

The systemc dir should be there in IC5141 too - it's installed if products 32500
or 90001 are installed.

The root cause of the problem with MMSIM60 is calling the file name with a
".spectre" suffix - using a ".scs" automatically means that the files are read
in spectre language mode. Or you have to use simulator lang=spectre at the top.

Regards,

Andrew.

On Tue, 15 Nov 2005 11:13:11 +0100, Gerard Wienk <g.j.m.wienk@##utwente##.nl>
wrote:

Hello Bernd,

Thanks a lot.

With this new release of Cadence you can also setup a MMSIM tree(I have
version 6.0.USR1). This tree contains UltraSIM but also a version of
SPECTRE. This setup has the required directory "systemc" which the
dfII tree has not.
If you put the PATH variable to mmsim/tools/bin in front of any dfII
paths then the MMSIM version of SPECTRE will be executed and compiling
will work!

But this version of SPECTRE cannot handle the way my design kit model
libraries are provided.
Here is some output:

-> Simulating `input.scs' on icetux5 at 5:21:01 PM, Mon Nov 14, 2005.
-> Using new Spectre Parser.
-> Error found by spectre during circuit read-in.
->"/cadappl/iclibs/CMOS18/../../tools/spectre/c15/include_nominal.spectre"
->1: Spectre "include" statements are not supported in spice language
->sections. Use "simulator lang = spectre" to introduce Spectre language
->sections.
->spectre terminated prematurely due to fatal error.

This include_nominal.spectre file looks like this:

include "fns_global.spectre" section=nominal
include "process.spectre"
include "if_CMOS18xxxxc15.spectre"
include "statistics.spectre"


So I deleted the MMSIM path variable and copied the "systemc" directory
to the dfII/tools directory.
This seems to work well, it compiles libahdlcmi.so and simulates the
circuit without error messages.

For historic reasons I always used SPECTRE_DEFAULTS=-E but with
IC5.1.41usr2 this setting gives following message:
cpp:unrecognized option'-$'


What are your thoughts about all these issues?

Thanks again for putting me on the right track.

Regards,

Gerard




Bernd Fischer > wrote:
Hi,

This is what Andrew told me about how Verilog-A compilation was handled
in DFII
in 5.1.41. I think he don't object that I post this here.

In IC5141, Verilog-A code is compiled to a shared library. It
converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a CMI
library
(compiled model interface).
It means that the first time you use a model it takes a little longer,
but on subsequent runs it just links in the shared library. The idea, of
course, is that the shared library should have better performance
than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that has
ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[fogh]

Gerard,
I have made a few notes on this and reported them to the people in
charge of this technology. If you want I can also look them up at my
desk (call 015 275 60 36 during work hours).

The -E option to select the old parser should work just fine. It a
default for me also, because it gives much better performance. Seeing
spectre hang for so long while parsing the whole model library,
including the dead part it too annoying. A lot of design work is done
with short simulations. I wish CDS would work towards shortening the
startup time instead of increasing it. In any case that parsing should
be more verbose, and it should also be cached. (veriloga compilation
could also be a bit more verbose).

I don t recognise that problem with -$ . What was the command line (on
top of the outfile) ?

Bernd Fischer > wrote:

Why didn't you put just a 'simulator lang=spectre' on top of
your 'include_nominal.spectre' file as the Spectre output tells you.
Then you probably could have used MMSIM.

To have the simulators UltraSim & Spectre in a different "Stream"
is the new Release Model of Cadence. I think to use it right away is
future proof.

Also I believe in MMSIM Cadence cleaned some mess in the
Spectre Parser, I saw a similar think with inline subcircuits.

Form me the Parser is more strict now, which not means that
this has to be worse. You have the chance to get Error Messages and
correct your Model Libraries due to that.

Don't know much about SPECTRE_DEFAULTS=-E, sorry.

Bernd


Gerard Wienk wrote:

Hello Bernd,

Thanks a lot.

With this new release of Cadence you can also setup a MMSIM tree(I have
version 6.0.USR1). This tree contains UltraSIM but also a version of
SPECTRE. This setup has the required directory "systemc" which the
dfII tree has not.
If you put the PATH variable to mmsim/tools/bin in front of any dfII
paths then the MMSIM version of SPECTRE will be executed and compiling
will work!

But this version of SPECTRE cannot handle the way my design kit model
libraries are provided.
Here is some output:

-> Simulating `input.scs' on icetux5 at 5:21:01 PM, Mon Nov 14, 2005.
-> Using new Spectre Parser.
-> Error found by spectre during circuit read-in.
->"/cadappl/iclibs/CMOS18/../../tools/spectre/c15/include_nominal.spectre"

->1: Spectre "include" statements are not supported in spice language
->sections. Use "simulator lang = spectre" to introduce Spectre language
->sections.
->spectre terminated prematurely due to fatal error.

This include_nominal.spectre file looks like this:

include "fns_global.spectre" section=nominal
include "process.spectre"
include "if_CMOS18xxxxc15.spectre"
include "statistics.spectre"


So I deleted the MMSIM path variable and copied the "systemc"
directory to the dfII/tools directory.
This seems to work well, it compiles libahdlcmi.so and simulates the
circuit without error messages.

For historic reasons I always used SPECTRE_DEFAULTS=-E but with
IC5.1.41usr2 this setting gives following message:
cpp:unrecognized option'-$'


What are your thoughts about all these issues?

Thanks again for putting me on the right track.

Regards,

Gerard




Bernd Fischer > wrote:

Hi,

This is what Andrew told me about how Verilog-A compilation was
handled in DFII
in 5.1.41. I think he don't object that I post this here.

In IC5141, Verilog-A code is compiled to a shared library. It
converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a CMI
library
(compiled model interface).
It means that the first time you use a model it takes a little
longer,
but on subsequent runs it just links in the shared library. The
idea, of
course, is that the shared library should have better performance
than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that
has ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[Andrew Beckett]

On Tue, 15 Nov 2005 23:46:26 -0500, fogh <adff@xs4all.nl> wrote:

Gerard,
I have made a few notes on this and reported them to the people in
charge of this technology. If you want I can also look them up at my
desk (call 015 275 60 36 during work hours).

The -E option to select the old parser should work just fine. It a
default for me also, because it gives much better performance. Seeing
spectre hang for so long while parsing the whole model library,
including the dead part it too annoying. A lot of design work is done
with short simulations. I wish CDS would work towards shortening the
startup time instead of increasing it. In any case that parsing should
be more verbose, and it should also be cached. (veriloga compilation
could also be a bit more verbose).

I don t recognise that problem with -$ . What was the command line (on
top of the outfile) ?

Several points here:

1. -E does not select the old parser. It enables the use of "cpp" to preprocess
the netlist - both with the new and old parser. -csfe switches to the old
parser in MMSIM60 (note this will be going away in MMSIM61, I believe).
2. The verilog-a compilation is incremental; it only recompiles if the Verilog-A
changes - so it's the first run that is typically slower. The time taken is
mostly down to gcc.
3. You can turn off the Verilog-A compilation by doing:
setenv CDS_AHDLCMI_ENABLE NO
4. You wouldn't want to see all the output messages from the Verilog-A
compilation all the time - which is why the log file for each compilation is
there.

Regards,

Andrew.

 

[Gerard Wienk]

Hi Bernd,

I tried that but then Spectre complained that there are syntax errors in
the statistics file. These files are part of a foundry supplied design
kit which I tend to leave as they are. I think this kit is just not
compatible with MMSIM yet. May be it will be fixed un the next release!

I also find Andrews suggestion, to use env. var. "CDS_AHDLCMI_ENABLE"
very elegant. Since the amount adhl code in the design kit is very small
is does not make much difference in simulation speed anyway.

I'm curious where i can find these kind of environment variables! Can't
find any reference in CDSDOC.


Regards,

Gerard




Bernd Fischer > wrote:

Why didn't you put just a 'simulator lang=spectre' on top of
your 'include_nominal.spectre' file as the Spectre output tells you.
Then you probably could have used MMSIM.

To have the simulators UltraSim & Spectre in a different "Stream"
is the new Release Model of Cadence. I think to use it right away is
future proof.

Also I believe in MMSIM Cadence cleaned some mess in the
Spectre Parser, I saw a similar think with inline subcircuits.

Form me the Parser is more strict now, which not means that
this has to be worse. You have the chance to get Error Messages and
correct your Model Libraries due to that.

Don't know much about SPECTRE_DEFAULTS=-E, sorry.

Bernd


Gerard Wienk wrote:

Hello Bernd,

Thanks a lot.

With this new release of Cadence you can also setup a MMSIM tree(I have
version 6.0.USR1). This tree contains UltraSIM but also a version of
SPECTRE. This setup has the required directory "systemc" which the
dfII tree has not.
If you put the PATH variable to mmsim/tools/bin in front of any dfII
paths then the MMSIM version of SPECTRE will be executed and compiling
will work!

But this version of SPECTRE cannot handle the way my design kit model
libraries are provided.
Here is some output:

-> Simulating `input.scs' on icetux5 at 5:21:01 PM, Mon Nov 14, 2005.
-> Using new Spectre Parser.
-> Error found by spectre during circuit read-in.
->"/cadappl/iclibs/CMOS18/../../tools/spectre/c15/include_nominal.spectre"

->1: Spectre "include" statements are not supported in spice language
->sections. Use "simulator lang = spectre" to introduce Spectre language
->sections.
->spectre terminated prematurely due to fatal error.

This include_nominal.spectre file looks like this:

include "fns_global.spectre" section=nominal
include "process.spectre"
include "if_CMOS18xxxxc15.spectre"
include "statistics.spectre"


So I deleted the MMSIM path variable and copied the "systemc"
directory to the dfII/tools directory.
This seems to work well, it compiles libahdlcmi.so and simulates the
circuit without error messages.

For historic reasons I always used SPECTRE_DEFAULTS=-E but with
IC5.1.41usr2 this setting gives following message:
cpp:unrecognized option'-$'


What are your thoughts about all these issues?

Thanks again for putting me on the right track.

Regards,

Gerard




Bernd Fischer > wrote:

Hi,

This is what Andrew told me about how Verilog-A compilation was
handled in DFII
in 5.1.41. I think he don't object that I post this here.

In IC5141, Verilog-A code is compiled to a shared library. It
converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a CMI
library
(compiled model interface).
It means that the first time you use a model it takes a little
longer,
but on subsequent runs it just links in the shared library. The
idea, of
course, is that the shared library should have better performance
than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that
has ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared object
file: No such file or directory

 

[Andrew Beckett]

On Wed, 16 Nov 2005 11:49:27 +0100, Gerard Wienk <g.j.m.wienk@##utwente##.nl>
wrote:

Hi Bernd,

I tried that but then Spectre complained that there are syntax errors in
the statistics file. These files are part of a foundry supplied design
kit which I tend to leave as they are. I think this kit is just not
compatible with MMSIM yet. May be it will be fixed un the next release!

I also find Andrews suggestion, to use env. var. "CDS_AHDLCMI_ENABLE"
very elegant. Since the amount adhl code in the design kit is very small
is does not make much difference in simulation speed anyway.

I'm curious where i can find these kind of environment variables! Can't
find any reference in CDSDOC.


Regards,

Gerard

spectre -h veriloga

mentions this. It should be in the Spectre documentation in cdsdoc (for MMSIM60,
at least), I'd have thought - since this is derived from the same data.

Regards,

Andrew.

 

[fogh]

Andrew Beckett wrote:

On Tue, 15 Nov 2005 23:46:26 -0500, fogh <adff@xs4all.nl> wrote:


Gerard,
I have made a few notes on this and reported them to the people in
charge of this technology. If you want I can also look them up at my
desk (call 015 275 60 36 during work hours).

The -E option to select the old parser should work just fine. It a
default for me also, because it gives much better performance. Seeing
spectre hang for so long while parsing the whole model library,
including the dead part it too annoying. A lot of design work is done
with short simulations. I wish CDS would work towards shortening the
startup time instead of increasing it. In any case that parsing should
be more verbose, and it should also be cached. (veriloga compilation
could also be a bit more verbose).

I don t recognise that problem with -$ . What was the command line (on
top of the outfile) ?



Several points here:

1. -E does not select the old parser. It enables the use of "cpp" to preprocess
the netlist - both with the new and old parser. -csfe switches to the old
parser in MMSIM60 (note this will be going away in MMSIM61, I believe).

Yes I realised only now that I got it mixed up. I meant -csfe
Is there a speed improvement in MMSIM61 ? In MMSIM60 the new parser is delaying
start of simulation by far too long. And that is, unlike veriloga, not cached
and happens every time.

2. The verilog-a compilation is incremental; it only recompiles if the Verilog-A
changes - so it's the first run that is typically slower. The time taken is
mostly down to gcc.
3. You can turn off the Verilog-A compilation by doing:
setenv CDS_AHDLCMI_ENABLE NO
4. You wouldn't want to see all the output messages from the Verilog-A
compilation all the time - which is why the log file for each compilation is
there.

 

[fogh]

Gerard,

there is not much veriloga in the model file, but there is certainly many
devices in your circuits using it (resistors with disto).

Gerard Wienk wrote:

Hi Bernd,

I tried that but then Spectre complained that there are syntax errors in
the statistics file. These files are part of a foundry supplied design
kit which I tend to leave as they are. I think this kit is just not
compatible with MMSIM yet. May be it will be fixed un the next release!

I also find Andrews suggestion, to use env. var. "CDS_AHDLCMI_ENABLE"
very elegant. Since the amount adhl code in the design kit is very small
is does not make much difference in simulation speed anyway.

I'm curious where i can find these kind of environment variables! Can't
find any reference in CDSDOC.


Regards,

Gerard




Bernd Fischer > wrote:

Why didn't you put just a 'simulator lang=spectre' on top of
your 'include_nominal.spectre' file as the Spectre output tells you.
Then you probably could have used MMSIM.

To have the simulators UltraSim & Spectre in a different "Stream"
is the new Release Model of Cadence. I think to use it right away is
future proof.

Also I believe in MMSIM Cadence cleaned some mess in the
Spectre Parser, I saw a similar think with inline subcircuits.

Form me the Parser is more strict now, which not means that
this has to be worse. You have the chance to get Error Messages and
correct your Model Libraries due to that.

Don't know much about SPECTRE_DEFAULTS=-E, sorry.

Bernd


Gerard Wienk wrote:

Hello Bernd,

Thanks a lot.

With this new release of Cadence you can also setup a MMSIM tree(I have
version 6.0.USR1). This tree contains UltraSIM but also a version of
SPECTRE. This setup has the required directory "systemc" which the
dfII tree has not.
If you put the PATH variable to mmsim/tools/bin in front of any dfII
paths then the MMSIM version of SPECTRE will be executed and compiling
will work!

But this version of SPECTRE cannot handle the way my design kit model
libraries are provided.
Here is some output:

-> Simulating `input.scs' on icetux5 at 5:21:01 PM, Mon Nov 14, 2005.
-> Using new Spectre Parser.
-> Error found by spectre during circuit read-in.
->"/cadappl/iclibs/CMOS18/../../tools/spectre/c15/include_nominal.spectre"

->1: Spectre "include" statements are not supported in spice language
->sections. Use "simulator lang = spectre" to introduce Spectre language
->sections.
->spectre terminated prematurely due to fatal error.

This include_nominal.spectre file looks like this:

include "fns_global.spectre" section=nominal
include "process.spectre"
include "if_CMOS18xxxxc15.spectre"
include "statistics.spectre"


So I deleted the MMSIM path variable and copied the "systemc"
directory to the dfII/tools directory.
This seems to work well, it compiles libahdlcmi.so and simulates the
circuit without error messages.

For historic reasons I always used SPECTRE_DEFAULTS=-E but with
IC5.1.41usr2 this setting gives following message:
cpp:unrecognized option'-$'


What are your thoughts about all these issues?

Thanks again for putting me on the right track.

Regards,

Gerard




Bernd Fischer > wrote:

Hi,

This is what Andrew told me about how Verilog-A compilation was
handled in DFII
in 5.1.41. I think he don't object that I post this here.

In IC5141, Verilog-A code is compiled to a shared library. It
converts the
Verilog-A code to C, and then compiles it with gcc (included in the
installation) to a shared library, and then links this in as a
CMI library
(compiled model interface).
It means that the first time you use a model it takes a little
longer,
but on subsequent runs it just links in the shared library. The
idea, of
course, is that the shared library should have better performance
than the
Verilog-A interpreter.

Until now I saw two issues with this.

1.) The GNU C Compiler which comes with the Cadence installation, will
be not installed correct, if you install form a different OS than
DFII was built for, e.g. You install on Solaris a DFII release for
Linux.

The Error msg. looks similar to yours

# Opening directory ahdlcmi (770)
# Opening directory
# ahdlcmi/_ncap.va.ahdlcmi/
# (770)
# Compiling ahdlcmi module library.
# Unable to compile ahdlcmi module library, see
# ahdlcmi/_ncap.va.ahdlcmi/
# for details
# Could not open ahdlcmi module library
# ahdlcmi/_ncap.va.ahdlcmi/obj
# /Linux2.4.21-15.ELsmp+gcc/optimize/4.0/libahdlcmi.so


Check if you installation directory
install_dir>/tools/systemc/gcc/3.2.3/install/bin
exist and if 'gcc' is installed there.
If not goto
install_dir>/tools/systemc/gcc/3.2.3/bin
check if 'gcc.t.Z' exist there and uncompress and untar it manualy
form this path
e.g.
% cd <install_dir>/tools/systemc/gcc
% uncompress gcc/3.2.3/bin/gcc.t.Z
% tar -xvf gcc/3.2.3/bin/gcc.t

If you don't find gcc.t.Z ask your Cadence Support.

2.) It happens in early 5.1.41 versions that compiled VerliogA modules
of user A has overwrite protections for group and other.
So if user B tries to simulate that VerilogA module precompiled by
user A he also gets compilation errors.
But I think the simulation than had problems.
If this is yours I suggest to upgrade to a higher 5.1.41 ISR.


Bernd

Gerard Wienk wrote:

Hello group,

I've just installed and tried IC5.1.41usr2, but I get these kind of
messages(below) when I try to simulate a circuit with SPECTRE that
has ahdl code in its model file.
It tries to compile something which it can't.
The simulation results seem to be ok though.
This does not happen in IC5.0.33usr2.
I was not able to find something on this topic.
Does anybody know what's wrong?

Regards,

Gerard

FROM SPECTRE.OUT:

Simulating `input.scs' on icetux5 at 2:02:12 PM, Mon Nov 14, 2005.
Opening directory ahdlcmi (770)
Opening directory

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

(770)
Compiling ahdlcmi module library.
Failed to compile ahdlcmi module library, see

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/

for details
Could not open ahdlcmi module library

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so

ahdlcmi/_misc_icetux1_cadappl_ictools_cadence_ic_5.1.41.USR2_tools.lnx86_dfII_samples_artist_ahdlLib_opamp_veriloga_veriloga.va.ahdlcmi/obj/Linux2.6.8-24.18-

bigsmp+gcc/optimize/libahdlcmi.so: cannot open shared
object file: No such file or directory

 

[Andrew Beckett]

On Wed, 16 Nov 2005 19:34:30 +0100, fogh <adff@CUTTHIS.xs4all.nl> wrote:

1. -E does not select the old parser. It enables the use of "cpp" to preprocess
the netlist - both with the new and old parser. -csfe switches to the old
parser in MMSIM60 (note this will be going away in MMSIM61, I believe).

Yes I realised only now that I got it mixed up. I meant -csfe
Is there a speed improvement in MMSIM61 ? In MMSIM60 the new parser is delaying
start of simulation by far too long. And that is, unlike veriloga, not cached
and happens every time.

There were some issues with the new parser being slow in some cases, but those
were fixed in an MMSIM60 ISR - certainly in the cases I've seen - with models
from a certain large pure-play foundry I was seeing a delay of a couple of
minutes with the new front end - which was PCR 804643 - fixed in
MMSIM60 ISR7 (6.0.1.131) which was released at the beginning of August, if
my memory is correct.

Andrew.

 

[fogh]

Andrew Beckett wrote:

On Wed, 16 Nov 2005 19:34:30 +0100, fogh <adff@CUTTHIS.xs4all.nl> wrote:


1. -E does not select the old parser. It enables the use of "cpp" to preprocess
the netlist - both with the new and old parser. -csfe switches to the old
parser in MMSIM60 (note this will be going away in MMSIM61, I believe).

Yes I realised only now that I got it mixed up. I meant -csfe
Is there a speed improvement in MMSIM61 ? In MMSIM60 the new parser is delaying
start of simulation by far too long. And that is, unlike veriloga, not cached
and happens every time.

There were some issues with the new parser being slow in some cases, but those
were fixed in an MMSIM60 ISR - certainly in the cases I've seen - with models
from a certain large pure-play foundry I was seeing a delay of a couple of
minutes with the new front end - which was PCR 804643 - fixed in
MMSIM60 ISR7 (6.0.1.131) which was released at the beginning of August, if
my memory is correct.

My mmsim is older. In the case of the technology Gerard mentionned, these are
not minutes, but 1 or less. Still, this is a big annoyance for a circuit
designer who works interactively, using short simulations.

 

[John O'Donovan]

As Andrew said the -E option just causes cpp to be called on the
netlist before Spectre actually parses it. On Linux, cpp is called as
follows,

/lib/cpp -traditional -$ ...

On my systems, which have GCC 2.96 and 3.2.3 installed -$ is a valid
option to cpp. Maybe you have a different version of cpp installed in
/lib/cpp. Use /lib/cpp --version to find the version.

With regard to performance and comparing the new Spectre parser with
the old (-csfe), the actual parser itself should always be faster.
Neither parser caches data between runs , so that is not the source of
the problem. Have you tried to disable the compilation of Verilog-A.
For small circuits this can easily dominate.

Best Regards,
John

 

[fogh]

John O'Donovan wrote:

As Andrew said the -E option just causes cpp to be called on the
netlist before Spectre actually parses it. On Linux, cpp is called as
follows,

/lib/cpp -traditional -$ ...

On my systems, which have GCC 2.96 and 3.2.3 installed -$ is a valid
option to cpp. Maybe you have a different version of cpp installed in
/lib/cpp. Use /lib/cpp --version to find the version.

With regard to performance and comparing the new Spectre parser with
the old (-csfe), the actual parser itself should always be faster.
I think that the new parser (at least in older-than-last-august

versions) is slower in practise only because it parses everything, even
the sections of the .scs not selected.

Neither parser caches data between runs , so that is not the source of
the problem. Have you tried to disable the compilation of Verilog-A.
For small circuits this can easily dominate.
Caching is not the problem, it is a possible solution for better

performance that I was proposing. But never mind, cadence R&D knows
their business and they can probably come up with many different
solutions to improve the parser performance.
I ll just make an SR if I find this performance problem also in recent
MMSIM.