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

[tymonx]

The -enable_cmdline_define_redefinition argument is not supported by the Cadence Xcelium. It simple doesn't exist.

I have access to all Xcelium versions from 21 to the latest 25.

xrun -helpall | grep -i enable_cmdline_define_redefinition

It returns nothing. Grepping also the docs directory it returns nothing.

Because of that added -enable_cmdline_define_redefinition argument, the xrun fails. This must be removed.

edalize/edalize/tools/xcelium.py

Line 155 in e33ebfb

"-enable_cmdline_define_redefinition",

I'm assuming that this argument was added to some kind of ancient version of Xcelium from 1876. Cadence is supporting Xcelium up to 2-4 years, older versions of Xcelium are nuked.

[tymonx]

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"]

[olofk]

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.

[tymonx]

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

[tymonx]

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.

[tymonx]

And PR was born #558