TimingConstraintsManager 2022.03

tracy6969

Thanks for the info.
Wondering if this could be a port listening problem, i.e., using different ports for each daemon may solve the issue ?

joshua2784920

tracy6969 发表于 2025-1-30 01:25
Thanks for the info.
Wondering if this could be a port listening problem, i.e., using different port ...

It is not port listening problem.


The snpslmd process creates LOCK files for all vendor daemons acquired so far, including the FISHD lock file, on the machine where it is running.
Even if this lock file is deleted, it is immediately regenerated.
Therefore, the only solution is to include the FISHD vendor when generating the license using scl_gen and to avoid running the FISHD daemon.
If this approach is taken, it is more appropriate to use the latest version of TimingConstraintsManager, which can be run as a daemon service under snpslmd.
However, including the FISHD vendor when generating the license with scl_gen is a complex and challenging process. While a method has been found to successfully perform this, it occasionally causes checkout and check-in issues.
This is why we do not use TimingConstraintsManager that requires the FISHD service.

joshua2784920

The latest version is  "timingconstmgr_vW-2024.09-SP2" that working with snpslmd daemon.