DReynolds wrote, on 04/03/08 12:45:
> Andrew, thanks for the post... I have seen this problem myself. If I
> set compile all and elaborate all to true, shouldn't this get rid of
> the inca and pak file issues?
>
> The part of your post I don't quite follow is the part about cds.lib.
> for example if my old cds.lib was
>
> DEFINE foo /tmp/dsk/path/foo
>
> and my new cds.lib is
>
> DEFINE foo /tmp/dsk/newpath/foo
> DEFINE foo_old /tmp/dsk/path/foo
>
> Why does the simulator care that foo used to be /tmp/dsk/path/foo?
> What is it that is looking in cds.lib and remembers what it used to
> be?
> Or is it that foo_old has the path that foo used to have... again what
> in the simulator noticing this and why doesn't recompiling fix it?
>
> thanx
>
> David
>
I'm surprised. It's normally the library name that's the problem, not the
path.
That's because the library name is stored within the pak file.
Note that a re-netlist and compile will not remove the pak file within the
library - it only affects the pak file underneath the ADE netlist
directory.
Unfortunately this is (if my memory is correct) seeded from the pak file
in the
library, so if that's messed up, the mess-up propagates.
Anyway, the workaround is to manually delete the pak file, and hopefully
we'll
fix things so that this gets done behind the scenes, or it is at least
smart
enough to ignore the duff pak file.
Regards,
Andrew.
|
