Stats

  • Locked Locked
  • Replies 8
  • Subscribers 67
  • Views 27915
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DLCSMD Errors

Chris Hopkins

Hi,

I'm getting the following compile error:

xmvlog: *E,DLCSMD: Dependent checksum verilog_package work.foo_pkg:sv (VST) doesn't match with the checksum that's in the header of: verilog_package work.foo_bar_pkg:sv (VST).
import foo_bar_pkg::*;

This is starting from a completely clean build. (Historic posts on this error have talked about removing INCA_libs as the solution).

Other than that I can't see what we could be doing here to cause this error. Any suggestions would be greatly received.

Kind Regards

  

Parents

  • The INCA_libs directory is called xcelium.d these days, but try the -clean and -cleanlib options first. 

  • in reply to cmarqu42

    Indeed, clean as noted makes no difference.

  • in reply to Chris Hopkins

    "xmhelp xmvlog DLCSMD" also suggests some causes, like two design units with the same name but different content or two compilations of the same file with different options - could this apply?

  • in reply to cmarqu42

    That is a really good point. I'm trying to pick through exactly what is happening with our packages as there are multiple RECOME warnings with this build. Many of those warnings referencing package foo as the package that is the cause of their recompilation. All the ones I've checked are seeming to be recompiled as package x is referenced in multiple other packages and so it is rebuilt for each of these candidate packages (not because of configuration differences).

    I don't have any evidence at the moment that there is any repetition of content, but we certainly have different parameters used with this module. I *hope* that isn't a problem though.

    To be clear, the two compilations would be coming not from the different parameters, but from any changes with build options and defines. At least that's my understanding of why a recompilation would be needed.

    Thanks

  • in reply to cmarqu42

    As some kind of last resort, "strace -f -o strace.log xrun ..." may also give you an idea what is being done to your files. (strace also has some powerful options for filtering.)

  • in reply to Chris Hopkins

    I believe you can also see these errors if the source code is compiled multiple times. For example, by using `include "mypackage.sv" in multiple places. Perhaps enclosing `include directives with `ifdefs would help.

    `ifndef MYPACKAGE
      `define MYPACKAGE
      `include "mypackage.sv"
    `endif

    Search your source code for every `include directive and see if there are duplicates.

  • in reply to TAM1

    Just discovered that this is indeed happening.

    Unfortunately this is 3rd party ip (hence me being so vague about some of the details so names redacted to protect...) so I can't actually edit the source.

    Thanks I now know what is wrong, how to fix it without being able to change the code is another issue entirely!

    Much appreciated. 

  • in reply to TAM1

    Good suggestion, though you'd normally protect the content of "mypackage.sv" that way, not every place where it's included (see e.g. https://en.wikipedia.org/wiki/Include_guard).

Reply Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.