bug(xcelium): the -enable_cmdline_define_redefinition argument is not supported for Xcelium 24 and below #532

Activity

1. tymonx commented on Jun 23, 2026

   

   tymonx

   on Jun 23, 2026

   Last edited by tymonx

   ContributorAuthor

   More actions

   When using Cadence Xcelium 24 (still supported):

   

   xrun: *SE,BDOPT: Unknown option -enable_cmdline_define_redefinition.
   

   From the xmhelp command:

   xmhelp xrun BDOPT
   xmhelp(64): 24.03-s005: (c) Copyright 1995-2024 Cadence Design Systems, Inc.
   xrun/BDOPT =
           The mentioned option is not handled by the xrun utility.
           (Default severity: 'SE')
   

   But the Xcelium 25 is accepting this option. Still, this option is not documented in any version of Xcelium.

   (xmvlog -help; xmvhdl -help; xmelab -help; xmsim -help; xrun -helpall) | grep -i -- enable_cmdline_define_redefinition
   

   And:

   grep -iR enable_cmdline_define_redefinition <xcelium_root_dir>/doc
   

   Returns nothing.

   It seems that this option was added silently by Cadence in the Xcelium 25.

   Conclusion, cannot use the xcelium backend with the Cadence Xcelium < 25 because of the -enable_cmdline_define_redefinition argument. User must use at least the Cadence Xcelium 25 with hotfixes and above.

   Possible fix could parse the version of the Xcelium to 3 elements tuple (like in case of the Python version). And do something like this:

   if version >= (25, 0, 0):
       args += ["-enable_cmdline_define_redefinition"]
2. tymonx

   changed the title [-]bug(xcelium): the -enable_cmdline_define_redefinition argument is not supported[/-] [+]bug(xcelium): the -enable_cmdline_define_redefinition argument is not supported for Xcelium 24 and below[/+] on Jun 23, 2026
3. olofk commented on Aug 10, 2026

   

   olofk

   on Aug 10, 2026

   Owner

   More actions

   Ouch... that makes things a bit complicated. The reason for having it was basically to allow different parts of a design to be compiled with different defines, and especially allow having identically named modules with different designs but located in different logical libraries. If we can find a way around that, I'm happy to let it go.
4. tymonx commented on Aug 10, 2026

   

   tymonx

   on Aug 10, 2026

   ContributorAuthor

   More actions

   Ouch... that makes things a bit complicated. The reason for having it was basically to allow different parts of a design to be compiled with different defines, and especially allow having identically named modules with different designs but located in different logical libraries. If we can find a way around that, I'm happy to let it go.

   But this is already supported by -makelib ... -endlib 🤔 You can even use it per file for the same library and define with different value like this:

   -makelib libname file1.sv -define KEY=VALUE1 -endlib
   -makelib libname file2.sv -define KEY=VALUE2 -endlib
   
5. tymonx commented on Aug 10, 2026

   

   tymonx

   on Aug 10, 2026

   Last edited by tymonx

   ContributorAuthor

   More actions

   One of my previous PR guarantees that the lib will be always set
   

   edalize/edalize/tools/xcelium.py

   Line 140 in e8e25d0

   lib = f.get("logical_name", "worklib")

   As affect of that, the xcelium backend will always use the -makelib <lib> <file> <defines> -endlib:

   edalize/edalize/tools/xcelium.py

   Lines 154 to 164 in 6c1afd6

   	if lib:
   	files_cmd += ["-makelib", lib]
   	for k, v in defines.items():
   	files_cmd += ["-define", f"{k}={v}"]
   	if file_type.startswith("systemVerilogSource"):
   	files_cmd += ["-sv"]
   	if file_type in self.FILE_TYPE_TO_FEATURE_FLAG:
   	files_cmd += [self.FILE_TYPE_TO_FEATURE_FLAG[file_type]]
   	files_cmd += fg[1]
   	if lib:
   	files_cmd += ["-endlib"]

   We can now safely drop the -enable_cmdline_define_redefinition. I will raise a PR for that.
6. tymonx commented on Aug 11, 2026

   

   tymonx

   on Aug 11, 2026

   ContributorAuthor

   More actions

   And PR was born #558