Global constants definition problem

Hi, Help is needed.

I have some global constants shared among several modules, so I set up a file to define a global package like the following:

Package MG_x_Constant is constant DATA_BITS : integer := 16; constant DATA_RANGE : real := (2.0**16);

-- constant DATA_BITS : integer := 64;

-- constant DATA_RANGE : real := (2.0**64);

-- used in all test bench constant DATABITS : integer := DATA_BITS;

end MG_x_Constant;

Package body MG_x_Constant is ... end MG_x_Constant;

In other modules, DATA_BITS, DATABITS are freely used.

This morning I found a problem: when I changed DATA_BITS from 16 to 64, the ModelSim sim window still shows constant DATABITS = 16 and it never changed, even though I tried to delete the module from library and re-compile it again. constant DATABITS = 16 doesn't change.

IN compilation order, the global package definition file is always the first one.

I though if the global constant definition changes, all its appearance should change, but it doesn't. Why?

What is wrong with the above statements?

Thank you.

Weng

Reply to
Weng Tianxiang
Loading thread data ...

Hello, Try to recompile ALL sources which references to this package. I think about modelsim don't check & update referenced variables under compilation process in other sources.

Best regards

Weng Tianxiang wrote:

Reply to
Jozsef

Hi Jozsef, I re-compiled every modules, but the constants in global package don't change as if they were compiled once and never re-compiled again.

I even deleted all work directory contents, recompile every modules, but constants in the global package still don't change.

That is what I have experienced.

Any other ideas?

Weng

Reply to
Weng Tianxiang

Maybe they are declared in more than one place.

-- Mike Treseler

Reply to
Mike Treseler

Hi MIke, Never!

I tried to move all constant definitions from package entity module to package body module, all constants usage are errors.

Weng

Reply to
Weng Tianxiang

Hi, Is it possible that the error happens because I have used 2 levels of constants:

constant DATA_BITS : integer := 16;

Reply to
Weng Tianxiang

...

I've just been through something similar. What happened in my case was:

the package was compiled into a library, and included in my desigh via "Library/Use" statements.

The library was mapped into a particular Modelsim directory, and this mapping was stored in modelsim.ini, in the directory where I was working on the package.

Later, when I worked on the design, I found it using an OLD version of the package - because its mapping for that library was in a DIFFERENT modelsim.ini file (because the design was in a different place from the package).

I got into this mess because this project was a combination of two older ones, and not a fresh start.

This may not be your problem, but it's worth checking the library mapping paths in ALL relevant versions of modelsim.ini are what you expect.

- Brian

Reply to
Brian Drummond

Hi, Thank you everyone who gave me an answer.

The problem is resolved, I would like to share the lesson I learned from this experience.

  1. Original code: DATABITS_16_32_64 DATABITS_16_32_64, DEPTH => LEVEL_X) port map ( ... ); end generate;

The problem is the following statement: DATABITS_16_32_64 64, DEPTH => LEVEL_X) port map ( ... ); end generate;

BlockRAM_64 : if DATABITS = 32 generate BlockRAM_0: BlockRAM generic map ( DATABITS => 32, DEPTH => LEVEL_X) port map ( ... ); end generate;

BlockRAM_64 : if(DATABITS /= 64 and DATABITS /= 32) generate BlockRAM_0: BlockRAM generic map ( DATABITS => 16, DEPTH => LEVEL_X) port map ( ... ); end generate; end generate;

Thank you.

Weng

Reply to
Weng Tianxiang

Weng Tianxiang:

Why do you make DATABITS_16_32_64 a signal? All your problems derive from that. It looks like a constant to me.

Something like this would evaluate before the generic maps: constant DATABITS_16_32_64: integer := (((DATABITS-1)/16)+1)*16;

DATABITS 4 to 16 : DATABITS_16_32_64 is 16 DATABITS 32 : DATABITS_16_32_64 is 32 DATABITS 64 : DATABITS_16_32_64 is 64.

Other cases irrelevant, I assume.

--
jr
Reply to
jr

Hi Jr, Wow! Wonderful !!!

Your answer is very clever and absolute better than mine. I will use your code immediately without any conditions.

I learned a trick from you.

Thank you very much.

Weng

Reply to
Weng Tianxiang

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.