SPECTRE can't read a dynamic linking file in other system

Dear ALSYSGUY,

Speaking (writing?) fo myself only, I don't think you provided enough information to provide any concrete suggestions. Helpful information that may allow those who monitor this forum to provide good answers includes:

1. The versions of spectre on both systems.

2. Are there any differences in the licenses or license features between the two systems?

3. What exact series of commands or tools on each system are you specifically using to create a netlist?

4. Are there any supporting files necessary for your model file that are not accessible or not included in the "target server"?

5. What exactly is the error message you experience on the "target" system where "Target server's spectre software doesn't accept so file's functions and turned down the netlist calculation."

6. Can you simplify the situation such that a netlist is composed of only your ".so" model and say, a voltage source and determine if a netlist is created on both systems?

Shawn

Thank you for your answer.

Here is the more information that you want

1. The spectre versions of both systems
  A: "spectre 20.1.0.348.isr10" (my system)
  B: "spectre_20.10.298.ISR09" or "spectre_19.1.0.mid.166_10-07-2019_ER_lnx86" (Target system)

2. Differentiation of two license??
  Sorry, I have no idea for license feature

3. Series of commands??
  Both system's OS is Redhat. So, netlist is written by vi editor. Is that correct answer?

4. Surpporting file

  I checked dependencies of library in both system. In my opinion supporting file or library issues doesn't matter for this problem.
  (If you want to know library dependency result, I'll write it later)

5. Exact error message on "Target system"?

 Here is the simple structure of Verilog-A file and netlist. (both systems exactly uses these Verilog-A and netlist file)

 First Verilog-A file(My_verilog.va)

  ```

  1. Define module  name 

  2. Define variable type and parameter 

  3. Import so file's function (Let's assume so file's function names are 'dummy_function_a' and 'dummy_function_b')

    3.1 import "CDS_VA_DPI" function integer dummy_function_a(real a, real b)

    3.2 import "CDS_VA_DPI" function real dummy_function_b(real d, real e, real f)

  4. Remaining process ...

  ```

  Next, netlist file

  ```

  1. Define simple option

  2.  ahdl_include "My_sofile.so" -cds_va_dpi

  3. ahdl_include "My_verilog.va"

  4. Calling Verilog-A's module

  5. Remaining process...

  ```

  And Here is the error message,

  ```

  Time for Elaboration: CPU = 53.971 ms, elapsed = 690.284 ms.

  Time accumulated: CPU = 192.161 ms, elapsed = 992.502 ms.

  Peak resident memory used = 74.8 Mbytes.

  Fatal error found by spectre during hierarchy flattening.

      FATAL (ASL-6267): The definition of C function 'dummy_function_a' is missing in

          Verilog-A module 'SKH_test_spectre'. Use 'ahdl_include "c_shared_libray"

          -cds_va_dpi' in netlist to load the C library that contains the C function and

          rerun the simulation.

      FATAL (ASL-6267): The definition of C function 'dummy_function_b' is missing in Verilog-A

          module 'SKH_test_spectre'. Use 'ahdl_include "c_shared_libray" -cds_va_dpi' in

          netlist to load the C library that contains the C function and rerun the

          simulation.

  Time for EDB Visiting: CPU = 1.036 ms, elapsed = 2.35105 ms.

  Time accumulated: CPU = 193.311 ms, elapsed = 994.966 ms.

  Peak resident memory used = 75.4 Mbytes.

  ```

6. Simplify the situation

  The so file and netlist file shares in both systems. (Is that correct answer? I'm not fully understand your question)

Best regards.

This would be best resolved by contacting customer support (submit a support case after logging in).

Now you've clarified that you're creating a Verilog-A DPI shared library, that at least makes it clearer what you're doing (it was not obvious from your original post). My assumption is that the shared library can't be loaded on the target system because of some incompatibility. What does "lsb_release -a" output on your system and the target system? (I'm just checking obvious things - beyond that I'd probably need the C code, Verilog-A and netlist, which is why I suggested customer support is the best route).

Andrew

I'm late for reply

Here is "lsb_release -a" info about both systems

Own system's info: 
```
LSB Version: :core-4.1-amd64:core-4.1-ia32:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-ia32:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-ia32:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.9.2009 (Core)
Release: 7.9.2009
Codename: Core
```

Target system's info:
```

LSB Version:       :core-4.1-amd64:core-4.1-ia32:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-ia32:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-ia32:desktop-4.1-noarch:languages-4.1-ia32:languages-4.1-noarch:printing-4.1-ia32:printing-4.1-noarch

Distributor ID:    RedHatEnterpriseServer

Description:       Red Hat Enterprise Linux Server release 7.6 (Maipo)

Release: 7.6

Codename:        Maipo
```

Plus, 
Several functions of ".so" file use specific library package. I modified the function to calculate without the library package.
By doing that step, SPECTRE successfully read ".so" file and calculate my model. 

Do anyone have experienced similar situation?

I assume it's nothing as simple as you not specifying LD_LIBRARY_PATH on the target system? (or not setting it correctly)?

If it's not that, I suggest you contact customer support (as I recommended earlier).

Andrew

Thank you for your reply.

I already checked LD_LIBRARY_PATH, and target system successfully read the ".so" file.

However, the SPECTRE couldn't read ".so" file's function contents.
 

I'll follow your suggestion(contact support)