Is this synthesizable? about snitch HOT 5 CLOSED

Hi,

$clog2() should be supported; it sounds to me like you are using the wrong language standard. Are you sure you are reading the RTL as SystemVerilog? Also, make sure your tool is up to date; we require SV 2017 (1800-2017) in various places.

from snitch.

Hi,

$clog2() should be supported; it sounds to me like you are using the wrong language standard. Are you sure you are reading the RTL as SystemVerilog? Also, make sure your tool is up to date; we require SV 2017 (1800-2017) in various places.

Hi~
Of course $clog2() is synthesizable. But the arguement of $clog2 shall be constant.

    function automatic integer unsigned idx_width (input integer unsigned num_idx);
        return (num_idx > 32'd1) ? unsigned'($clog2(num_idx)) : 32'd1;
    endfunction

However, the function idx_width input is integer unsigned(this is not const) and it is used directly in $clog2.
Eventhough the real argument of idx_width is const, the synthesis tool(=design-compiler) interpret the argument of $clog2 is variable.
It's not a constant from a language point of view

ps. Please re-open this issue. Current version is not synthesizable.

commit 989a0bc3987d83ef077b51e5b9a1adfc42f3cde7
Author: GiannaP <[email protected]>
Date:   Mon Mar 14 14:16:06 2022 +0100

from snitch.

Hi,

Current version is not synthesizable

Wrong. We can only directly support you in the use of FOSS tools with our RTL, but I can assure you that the RTL in this exact commit is fully synthesizable. I suggest you carefully consult your tool's documentation for the error you encountered.

It's not a constant from a language point of view

Wrong. According to 1800-2017, all math functions (including $clog2()) may be used in constant expressions, constant expressions may be used in constant functions, and idx_width() fulfills all other criteria of a constant function. So unless idx_width() is called with non-constant parameters (in which case you should provide a call site), this should not be an issue.

Either way, this remains closed as we do not intend to discuss the use of non-free tools.

from snitch.

Wrong. According to 1800-2017, all math functions (including $clog2()) may be used in constant expressions, constant expressions may be used in constant functions, and idx_width() fulfills all other criteria of a constant function. So unless idx_width() is called with non-constant parameters (in which case you should provide a call site), this should not be an issue.

Either way, this remains closed as we do not intend to discuss the use of non-free tools.

Hi,
Thank you for your comments.

I fully understand you don't want discuss the use of non-free tools.
But I've just impressed your snitch paper(https://arxiv.org/abs/2002.10143) and I want to profile snitch complex core using DC-2018.06.

From the that paper, snitch is synthesized using DC-2017.09
There are 3 DC synthesis error points and all errors are caused $clog with variables.
The one is in idx_index and others are in ecc_decoe.sv and ecc_encode.sv(actually same part)

    for (int unsigned i = 1; i < unsigned'($bits(code_word_t)) + 1; i++) begin
      // if i is a power of two we are indexing a parity bit
      if (unsigned'(2**$clog2(i)) != i) begin
        data_wo_parity[idx] = correct_data[i - 1];
        idx++;
      end
    end

int is not constant and you can see similar issue in this link https://stackoverflow.com/questions/62035337/how-to-slicing-array-interface-in-system-verliog

from snitch.

Hi,

This is again wrong. Math functions like $clog2() may be used in constant expressions themselves, but that does not mean their arguments need to be constant expressions, unlike in the example of slicing interfaces you point to. In fact, the standard has no such requirement and even explicitly states that math functions can be used in constant expressions as long as all their arguments are also constant expressions, suggesting that they do not need to be.

Furthermore, the code you are now referring to is from a different repository we included as a dependency (pulp-platform/common_cells) and, to the best of my knowledge, the modules ecc_encode and ecc_decode are never instantiated in Snitch RTL.

Lastly, you are now referring to completely different code than before; we were discussing idx_width() from cf_math_pkg before.

Please do not open an issue when there is no identifiable issue. This RTL is synthesizable on our end, and my best guess is that you are doing it wrong. We are happy to help, but we can only fix issues that exist on our end.

from snitch.