Forum Discussion

Sakib's avatar
Sakib
Icon for New Contributor rankNew Contributor
2 months ago

Issue with MIPI CSI2 Encrypted IP File During Project Integration

Hi,

I am working on a project where I have integrated two separate projects into a single top-level design.

Project A includes the MIPI CSI2 IP and other related components.

Project B contains the logic to process the output data generated by the MIPI CSI2 IP.

When I compile both projects individually, they complete successfully without any errors.

However, after instantiating both projects together in a single top-level wrapper, I encounter a compilation error originating from the generated encrypted file of the MIPI CSI2 IP.

I have attached the error snapshot for your reference.

Could you please help identify the possible cause of this issue? Is there any known limitation or configuration requirement when integrating the MIPI CSI2 IP with additional logic in the same top-level design?

Thanks.

4 Replies

  • Without the .qar project to reproduce the issue, it is difficult to determine the exact root cause.

    Based on the reported error, the most likely cause is that the merged project is changing the Verilog compiler directive environment seen by the generated MIPI CSI2 encrypted files.
     

    The key message is:

    net type must be explicitly specified for 'in_clk' when default_nettype is none
     

    This usually indicates that a file compiled earlier in the project has enabled default_nettype none, and that setting remains active when the MIPI-generated file is compiled.

    A possible workaround is to limit default_nettype none usage to user RTL only, and restore default_nettype wire before the MIPI CSI2 IP files are compiled.
     

    Regards,
    Richard Tan

  • BCuze's avatar
    BCuze
    Icon for Occasional Contributor rankOccasional Contributor

    I suspect the Altera SV code for the fifo isn't optimal (probably missing "logic" in the port declaration).

    Note however that while using `default_nettype none was a recommended practice in Verilog, it has become -alas- a bad idea in SystemVerilog. I suggest you remove it in your (wrapper ?) code.

  • BCuze's avatar
    BCuze
    Icon for Occasional Contributor rankOccasional Contributor

    Yes, that's what I suspected, not very good sv code :-(.
    So make sure you don't use `default_nettype none on your code.

     

     

  • Thank you for the feedback. Would you mind sharing a .qar test case that reproduces this error so that I can provide it to our tool specialist for further investigation?

    Regards,
    Richard Tan