Modelsim : Problem with generics

[XSterna]

Hi,

I am having a problem with my generics parameters when simulating my
design.

I have created an entity with 2 generics parameters with default
values. When I modify those values in the VHDL source and re-simulate
the entity, the generics parameters keep the same values than
previously.

Here a bit of code to illustrate it. This is the part of my generic
declaration :

generic(
Nbits : integer := 8; -- Number of bits require for the counter
M : integer := 180 -- Counter Modulo
);

If I simulate the component, I will have M=180.

If I change the value to 190 for example, if I compile the "new"
source and then simulate it, I still have M=180.

I found on the web a command to change the value of M ( vsim -GM=190 )
but I would like to know how to make my changes taking into account by
ModelSim directly.

I wonder I have maybe a misunderstanding of the generics but I am
totally clueless on how to solve this problem !

If someone could help me, it would be great !

Regards,

Xavier

 

[Mike Treseler]

XSterna wrote:

I am having a problem with my generics parameters when simulating my
design.
....
If I change the value to 190 for example, if I compile the "new"
source and then simulate it, I still have M=180.

I found on the web a command to change the value of M ( vsim -GM=190 )
but I would like to know how to make my changes taking into account by
ModelSim directly.

Maybe you don't have a generic map on the testbench entity.
See the testbench here: http://mysite.verizon.net/miketreseler/
for an example.

If you aren't using vsim -G then you might be better off
with a packaged constant for these values.

-- Mike Treseler

 

[Mark McDougall]

XSterna wrote:

If I change the value to 190 for example, if I compile the "new" source
and then simulate it, I still have M=180.

I think you'll find that you need to re-compile all modules which
*instantiate* that entity, not just the file with the entity implementation.

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

 

[Mike Treseler]

XSterna wrote:

You are right I don't have a generic map on my testbench entity.

In my example, I used the testbench generic clause for
defaults that could be overridden from the command line.
A subset were port mapped to the DUT instance.
I now use packages except for command line sim options.

But I
don't understand why I need some since I have initialise the generics
in my component entity.

I use direct instances rather than components.
Much less confusion.

-- Mike Treseler

 

[XSterna]

On 17 juil, 22:14, Mike Treseler <mtrese...@gmail.com> wrote:

Maybe you don't have a generic map on the testbench entity.
See the testbench here:http://mysite.verizon.net/miketreseler/
for an example.

If you aren't using vsim -G then you might be better off
with a packaged constant for these values.

-- Mike Treseler

Thank you for your answer

You are right I don't have a generic map on my testbench entity. But I
don't understand why I need some since I have initialise the generics
in my component entity. If I need to create a generic map then I don't
see the interest of the generics initialisation ...
X

 

[XSterna]

Thank you everyone for your answers !

I find how to solve my problem !

Modelsim is creating a _opt file everytime I compile my entity. If I
don't delete the file from the 'work' library, the generics don't get
changed. If I do so, my changes are taking into accounts. It is quite
strange since I don't know what is this _opt and I don't feel this is
the common sense having to delete this but anyway, I have what I
wanted !


On 18 juil, 01:33, "KJ" <kkjenni...@sbcglobal.net> wrote:

You don't need a generic map unless
- You want to override the defaults
- An input does not have a default specified.

I unsterstood that so that's why I was quite surprised having to make
a generic map to change the values of my generics.

In addition to the entity, do you have a component definition? If so, do
you have the same default values on the component that you have on the
entity? Typically I don't use components and don't recall which default
value takes precedence, but I seem to recall similar nastiness when the
default values differed between component and entity and that could be what
is going on for you.

I am using component definition in my testbench but in fact, I don't
declare the generics, only the ports.

You wrote that you are not using components. Since I am quite a
beginer in VHDL, I would be insterested to understand why. I felt it
was mandatory to combine several entity for example. In my VHDL
knowledge, I create entity to create a design and then a component in
a testbench to "materialise" the entity and being able to link
different entities together.

But I understand that I have some lacks in my VHDL understanding
because I just read my testbench and after a new simulation I realised
that I don't really understand the use of "configuration" blocks. I
just comment it, run the simulation and in fact, I have exactly the
same I had before ... I will read more about this

I usually just directly instantiate the entity,

I think this is the answer to my previous question, but I don't really
understand what you mean ...

I doubt that it's a Modelsim problem...take a look for those component
definitions, I'll bet that's where the problem is.

I feel the same about the Modelsim problem supposition, but I still
feel pretty strange about the compilation thing. Because I often
directly simulate some entities designs without any testbench and the
"generic problem" still occur if I don't delete the _opt file. In my
example, I am simulating a modulo M counter. I define the default M in
the entity declaration and I am simulating this basic architecture
without any testbench. I have just a CLK, Reset and output signal, so
to quickly check it I am just making the signal with ModelSim. With
this basic use, I would expect not having any trouble when I just
recompile my file after a change in the generic value.

On 18 juil, 01:56, Mark McDougall <ma...@vl.com.au> wrote:

I think you'll find that you need to re-compile all modules which
*instantiate* that entity, not just the file with the entity implementation.

Believe me, I tried it a lot of time but it did not change anything...




On 18 juil, 01:58, Mike Treseler <mtrese...@gmail.com> wrote:

But I
don't understand why I need some since I have initialise the generics
in my component entity.

I use direct instances rather than components.
Much less confusion.

Same question than for KJ, what to you mean by the use of instances ?

Regards

 

[Mike Treseler]

XSterna wrote:

You wrote that you are not using components. Since I am quite a
beginner in VHDL, I would be interested to understand why.

Much less typing.
Here's an example:
http://groups.google.com/groups/search?q=entity+add_1_bit+component

-- Mike Treseler

 

[KJ]

On Jul 18, 5:29 am, XSterna <XSte...@gmail.com> wrote:

Thank you everyone for your answers !

I find how to solve my problem !

Modelsim is creating a _opt file everytime I compile my entity. If I
don't delete the file from the 'work' library, the generics don't get
changed. If I do so, my changes are taking into accounts. It is quite
strange since I don't know what is this _opt and I don't feel this is
the common sense having to delete this but anyway, I have what I
wanted !

Deleting the _opt file is just a temporary work around. It might be
getting you going but it's not necessary, deleting the files is
working around the problem not fixing it or understanding it, so read
on.

On 18 juil, 01:33, "KJ" <kkjenni...@sbcglobal.net> wrote:



In addition to the entity, do you have a component definition?  If so, do
you have the same default values on the component that you have on the
entity?  Typically I don't use components and don't recall which default
value takes precedence, but I seem to recall similar nastiness when the
default values differed between component and entity and that could be what
is going on for you.

I am using component definition in my testbench but in fact, I don't
declare the generics, only the ports.

Using components creates some additional issues that you're running
into right now. When you change the default values on the entity you
also need to recompile anything that instantiates that entity as Mark
pointed out. I'm assuming that your testbench is not in the same
physical file as the thing you're testing otherwise both would have
been compiled together.

Had you not used component definitions, Modelsim would have reported
an error that your testbench entity needs to be recompiled because the
entity has changed (changes to default values *are* changes to the
entity, not just adding/removing a signal or generic). You would've
then dutifully recompiled the testbench and never ran into the issue
that you've brought up here. It also sounds like you've put the
component definition in the same file as the testbench (I'm
guessing). By doing that Modelsim thinks everything is fine and vsim
will work but you'll get some issues.

The only sound way I've been able to come up with to use components is
- In the same file as the entity, make a package and put the component
definition in that package.
- When changing anything in the entity (or package), copy/paste the
entire interface (generics and ports) to the package (or entity).
That makes sure that there are no discrepancies between the entity and
the package.
- Never declare a component for an entity in any other file.

The other way is to simply not use component definitions. The syntax
to do this is only slightly different than when you use components.

Direct entity instantiation:
u1 : entity work.my_entity generic map(...) port map(...);

Using a previously defined component:
u1 : my_entity generic map(...) port map(...);

You wrote that you are not using components. Since I am quite a
beginer in VHDL, I would be insterested to understand why. I felt it
was mandatory to combine several entity for example.

It's not mandatory. Using components can lead to strange behaviour
(like you're seeing).

In my VHDL
knowledge, I create entity to create a design and then a component in
a testbench to "materialise" the entity and being able to link
different entities together.

No, what the component definition does is to allow you to play games
with using completely different models (i.e. totally different
entities). Components also allow you to compile files in any order
(in theory). In practice, as your example is showing you, there will
almost always be file compile order dependencies that can lead to
strange behaviour (like you're seeing) when it would be better if it
simply threw an error message (saying that entity such-and-such needs
to be recompiled because so-and-so is out of date).

By defining components in the file that is trying to *use* the widget,
(where the entity/architecture for the widget is in a different file)
you're inviting strange problems to occur...although everything will
'compile' just fine and vsim will start up and run...you just won't
get the intended result. For most people who are trying to get things
done, they would much rather have the compiler flag some sort of
problem than have to debug down to it at run time.

But I understand that I have some lacks in my VHDL understanding
because I just read my testbench and after a new simulation I realised
that I don't really understand the use of "configuration" blocks.

Since you're a beginner, I'd strongly urge you to use direct entity
instantiation as I've shown above and avoid components. I realize
that many textbooks and example code use components, but those same
references also preach on about the virtues of other discredited
techniques (i.e. two or three process state machines instead of single
process; use of std_logic_arith instead of numeric_std are two prime
examples that keep popping up in this newsgroup).

Components do have their place, but it's a relatively small niche in
my opinion so it should be used in those niches and not used
routinely.

I
just comment it, run the simulation and in fact, I have exactly the
same I had before ... I will read more about this

Configuration blocks are yet another step up the ladder in terms of
complexity and being able to play games with the code. You'll need
components in order to use configuration blocks but use of
configuration blocks is useful in a fairly narrow niche (many times
never even needed). They're worth learning at some point, but keep in
mind my advice about where to physically put the component definition
and how you should insure that BOTH the source and the compilation
results of the component are always in sync with the entity.

I usually just directly instantiate the entity,

I think this is the answer to my previous question, but I don't really
understand what you mean ...

See example earlier in the post for the syntax.

On 18 juil, 01:56, Mark McDougall <ma...@vl.com.au> wrote:

I think you'll find that you need to re-compile all modules which
*instantiate* that entity, not just the file with the entity implementation.

Believe me, I tried it a lot of time but it did not change anything...

If this still doesn't work, you might consider posting some more
detail about how you've got the files structured, where the component
definition(s) are, where the entity is, etc. It will still likely
come down to a file dependency issue in the end, but it could also be
a file system type of issue. The details of what your widget is doing
are not relevant. Below I've posted a simple example as well to look
at that mimics what I think you've described.

-- START OF CODE
entity foo is
generic(x: integer := 2);
port(y: out integer);
end foo;

architecture rtl of foo is
begin
assert false
report foo'path_name & "x=" & integer'image(x)
severity NOTE;
end rtl;

entity tb_foo is
end tb_foo;

architecture rtl of tb_foo is
component foo is
--** generic(x: integer := 1);
port(y: out integer);
end component;
begin
U1 : foo; -- Use the component
U2 : entity work.foo ; -- Use the entity
end rtl;
-- END OF CODE
When the above is all in one physical file, running Modelsim produces
the following.

vsim tb_foo; run -a
# vsim tb_foo
# Loading std.standard
# Loading work.tb_foo(rtl)
# Loading work.foo(rtl)
# ** Note: :tb_foo:u2:x=2
# Time: 0 ns Iteration: 0 Instance: /tb_foo/u2
# ** Note: :tb_foo:u1:x=2
# Time: 0 ns Iteration: 0 Instance: /tb_foo/u1

Changing the value of the generic to something else produces the
correct result (i.e. the changed value is written out).

I use direct instances rather than components.
Much less confusion.

Same question than for KJ, what to you mean by the use of instances ?

VHDL calls it direct entity instantiation. When your testbench code
plops down the thing that you're trying to test, what it is doing is
creating an 'instance' of that thing. In my example above I had two
instances: one of the entity foo, the other of the component foo.

Kevin Jennings

 

[XSterna]

Thank you very much for your help and the time you spend on "my
case"

I really like to do things in he right way so your advices are really
previous to me !

On 18 juil, 13:19, KJ <kkjenni...@sbcglobal.net> wrote:

Deleting the _opt file is just a temporary work around. It might be
getting you going but it's not necessary, deleting the files is
working around the problem not fixing it or understanding it, so read
on.

I guessed so because usually deleting a file to make something right
does not seems to be very appropriate

Using components creates some additional issues that you're running
into right now. When you change the default values on the entity you
also need to recompile anything that instantiates that entity as Mark
pointed out. I'm assuming that your testbench is not in the same
physical file as the thing you're testing otherwise both would have
been compiled together.

Your assumption is right, I always have a file for each entity I have
and a separate testbench for the simulation. I usually "build" a
circuit in the testbench that links different entities.

Had you not used component definitions, Modelsim would have reported
an error that your testbench entity needs to be recompiled because the
entity has changed (changes to default values *are* changes to the
entity, not just adding/removing a signal or generic). You would've
then dutifully recompiled the testbench and never ran into the issue
that you've brought up here. It also sounds like you've put the
component definition in the same file as the testbench (I'm
guessing). By doing that Modelsim thinks everything is fine and vsim
will work but you'll get some issues.

Your right again, my components are defined in the testbench. I
previously had a sort of visualisation of VHDL programming where
entities and there architecture were the logical part of the design,
then the component were the sort of physical aspect of it and allowed
me to wired my circuit.

I now understand that it is not really the idea. I will take some time
to read more about this. I just begin to work again on VHDL after
about 1 year so I maybe forgot things.

The only sound way I've been able to come up with to use components is
- In the same file as the entity, make a package and put the component
definition in that package.
- When changing anything in the entity (or package), copy/paste the
entire interface (generics and ports) to the package (or entity).
That makes sure that there are no discrepancies between the entity and
the package.
- Never declare a component for an entity in any other file.

This is the "funny" part of my problem because my electronic teacher
learned me exactly like that !

Entities in a file with there architecture, testbench in an other with
components refering to the entities and configuration.

The other way is to simply not use component definitions. The syntax
to do this is only slightly different than when you use components.

Direct entity instantiation:
u1 : entity work.my_entity generic map(...) port map(...);

Using a previously defined component:
u1 : my_entity generic map(...) port map(...);

Until now, I was using the second one.

No, what the component definition does is to allow you to play games
with using completely different models (i.e. totally different
entities). Components also allow you to compile files in any order
(in theory). In practice, as your example is showing you, there will
almost always be file compile order dependencies that can lead to
strange behaviour (like you're seeing) when it would be better if it
simply threw an error message (saying that entity such-and-such needs
to be recompiled because so-and-so is out of date).

By defining components in the file that is trying to *use* the widget,
(where the entity/architecture for the widget is in a different file)
you're inviting strange problems to occur...although everything will
'compile' just fine and vsim will start up and run...you just won't
get the intended result. For most people who are trying to get things
done, they would much rather have the compiler flag some sort of
problem than have to debug down to it at run time.

I will read more about component and configuration because it is quite
oscure to me now. I had a sort of understanding which seems to be 80%
wrong

About the order of compilation, I still don't really get it when I
look at my problem. As I told you before, when I had this problem I
tried a lot of things and the "compile all" was part of it. I
currently have 3 files : the counter, the controller and the testbench
(i am programming a RS232 controller). The compile order is : 0-
counter ; 1-controller ; 2-testbench. From what I understood, it his
the right order since the entity should be compile before using it in
another file (the testbench in that case). But if I change the value
of the generic in the counter file, if I compile all, I still have the
previous value I used before.

But what I saw is it seems that the testbench does not recompile
because it has not been modified (compile properties for compile
menu). So I fakely change the file to resave it, i recompile all but I
still have the same problem. I have to admit that I still do not have
delete my components and use what you said, but I will explain later
why.

Since you're a beginner, I'd strongly urge you to use direct entity
instantiation as I've shown above and avoid components.

I will ! I am not fanatic of component I just want to have something
working well and in the appropriate way.

If this still doesn't work, you might consider posting some more
detail about how you've got the files structured, where the component
definition(s) are, where the entity is, etc. It will still likely
come down to a file dependency issue in the end, but it could also be
a file system type of issue. The details of what your widget is doing
are not relevant. Below I've posted a simple example as well to look
at that mimics what I think you've described.

As I told you before I still don't have change the component (but I
will !) so it is still not working well, even with the "compile all"
technique with the order i believe is appropriate.

If I still did not do it it's because I have the same problem with
what I think is a simple simulation and where all you said is what I
am doing.

When I am simulating the entity of my counter (the entity itself
without any testbench or component), I have the same problem. What is
strange to me is that my file looks like the example you gave me
(without the testbench since in that case I am not using it).

So here is the entity I am trying to simulate :


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

entity baud_clk is
generic(
Nbits : integer := 8; -- Number of bits require for the counter
M : integer := 212 -- Counter Modulo
);

Port(
clk : in STD_LOGIC; -- Clock in
rst : in STD_LOGIC; -- reset
baud_tick : out STD_LOGIC -- Output tick at the baud frequency
);
end baud_clk;

architecture arch_baud_clk of baud_clk is
signal counter: unsigned(Nbits-1 downto 0);
signal counter_next: unsigned(Nbits-1 downto 0);
begin

process(clk,rst)
begin
if (rst = '1') then
counter <= (others => '0'); -- reset of the counter
elsif (clk'event and clk='1') then
counter <= counter_next;
end if;
end process;
counter_next <= (others =>'0') when counter=(M-1) else
counter + 1;
baud_tick <= '1' when counter = (M-1) else '0';
end arch_baud_clk;


This is not my own design since I found it in a book.

My problem occurs with this procedure :

1°/ I compile it
2°/ I go to the library tab and I simulate it

I can see in the objects 'M = 212'.

3°/ I change the M value in the file
4°/ I recompile it
5°/ I run a new simulation the same way I did in 2°/

I still have in my objects 'M=212'

In that case, I am just using my counter file, without any component
or testbench involved ...
This is very frustrating

Xavier

 

[KJ]

On Jul 18, 9:51 am, XSterna <XSte...@gmail.com> wrote:

The only sound way I've been able to come up with to use components is
- In the same file as the entity, make a package and put the component
definition in that package.
- When changing anything in the entity (or package), copy/paste the
entire interface (generics and ports) to the package (or entity).
That makes sure that there are no discrepancies between the entity and
the package.
- Never declare a component for an entity in any other file.

This is the "funny" part of my problem because my electronic teacher
learned me exactly like that !

Entities in a file with there architecture, testbench in an other with
components refering to the entities and configuration.

Well, that's not quite what I said. Putting component definitions in
a file with the testbench violates the rule about "Never declare a
component for an entity in any other file."

Package (where the component is declared), entity and architecture are
best put into a single file. That way any change to any of them
causes all three to get recompiled if you simply compile the out of
date files. If you've made a change that requires you to recompile a
higher level thing (like the testbench), then Modelsim will error out
telling you exactly which thing needs to be re-compiled and soon as
you start a new sim.

Testbenches go in a separate file (as you're doing) since they are
just something that is using the entity.

About the order of compilation, I still don't really get it when I
look at my problem. As I told you before, when I had this problem I
tried a lot of things and the "compile all" was part of it. I
currently have 3 files : the counter, the controller and the testbench
(i am programming a RS232 controller). The compile order is : 0-
counter ; 1-controller ; 2-testbench. From what I understood, it his
the right order since the entity should be compile before using it in
another file (the testbench in that case). But if I change the value
of the generic in the counter file, if I compile all, I still have the
previous value I used before.

But what I saw is it seems that the testbench does not recompile
because it has not been modified (compile properties for compile
menu). So I fakely change the file to resave it, i recompile all but I
still have the same problem.

You could also just select a file and compile it...but like you said,
compile all should do the trick.

When I am simulating the entity of my counter (the entity itself
without any testbench or component), I have the same problem. What is
strange to me is that my file looks like the example you gave me
(without the testbench since in that case I am not using it).

So here is the entity I am trying to simulate :

And when I copy/pasted your code and ran 'vsim work.baud_clk' I'm
seeing the generic 'M' set correctly (i.e. first M=212, then I tried
M=21 and lastly M=2.

My guess is that you're not vsim-ing the entity that you think you are
when you go to the library window on the GUI and start a sim. Try
entering the following command:

vsim work.baud_clk

Then on the 'sim' tab click on one of the processes and see what 'M'
is set to.

If that doesn't work, then maybe you've got a couple 'baud_clk'
entities in your files somehow. Go to the 'Library' tab and expand
the 'work' library. Inside there you'll see all of the entities that
have been compiled all the way back to when you started this project
or when you last cleaned everything out of 'work'. Select all of them
and delete them. Now you'll have nothing in the work library.
Compile just the one file that has the baud_clk entity and see if 'M'
is set correctly and that you can change it.

KJ

 

[Kevin Neilson]

Using a previously defined component:
u1 : my_entity generic map(...) port map(...);

Thanks for this; although I'm not an expert in VHDL, I can't believe I
didn't know one could do this. This certainly helps to minimize the
verbosity when it provides no additional value. -Kevin

 

[XSterna]

On 18 juil, 17:37, KJ <kkjenni...@sbcglobal.net> wrote:

Well, that's not quite what I said. Putting component definitions in
a file with the testbench violates the rule about "Never declare a
component for an entity in any other file."

Package (where the component is declared), entity and architecture are
best put into a single file. That way any change to any of them
causes all three to get recompiled if you simply compile the out of
date files. If you've made a change that requires you to recompile a
higher level thing (like the testbench), then Modelsim will error out
telling you exactly which thing needs to be re-compiled and soon as
you start a new sim.

Testbenches go in a separate file (as you're doing) since they are
just something that is using the entity.

Alright I understand the principle and I also think it's better for me
to put everything related to an entity in the same file.

And when I copy/pasted your code and ran 'vsim work.baud_clk' I'm
seeing the generic 'M' set correctly (i.e. first M=212, then I tried
M=21 and lastly M=2.

My guess is that you're not vsim-ing the entity that you think you are
when you go to the library window on the GUI and start a sim. Try
entering the following command:

vsim work.baud_clk

Then on the 'sim' tab click on one of the processes and see what 'M'
is set to.

If that doesn't work, then maybe you've got a couple 'baud_clk'
entities in your files somehow. Go to the 'Library' tab and expand
the 'work' library. Inside there you'll see all of the entities that
have been compiled all the way back to when you started this project
or when you last cleaned everything out of 'work'. Select all of them
and delete them. Now you'll have nothing in the work library.
Compile just the one file that has the baud_clk entity and see if 'M'
is set correctly and that you can change it.

Well ... I have done everything I could regarding to what you said and
I still have the same problem. To have something "clean" I create a
new project with my 3 files. I compile everything, simulate the
baud_clk and at the first run I had the good M value. When I change
the value (after 'end simulation' ) I recompile the file and ... the M
value did not change.

To be exactly in the same situation than you, I then create a new
project with only the baud_clk file. I used the command control 'vsim
work.baud_clk' and for the 2nd simulation, i got the same problem.

So I see twos possibilities :
- There is something wrong with my ModelSim version (ModelSim SE 6.2b)
- I am not compiling right, maybe there are some configuration to
make. I am currently compiling with the GUI, selecting the file in the
'Project' tab and then compile with the 'Compile' button in the
toolbar or 'Compile selected' in the right-click menu.

The _opt directory is created by the vopt optimiser (enabled by default
after I believe 6.2). If you run vsim -novopt this directory is not created.
However, vsim/vopt should detect a different generic argument and
re-optimise the relevant files so this looks like a bug. Log it with Mentor
if you are using Modelsim 6.4,

I am using the 6.2b so maybe this is the problem ... I will try to see
if I can get a newer version in my university.

 

[XSterna]

Finally, my problem was coming from the version of ModelSim I had ...

I download the 6.4 student version and now everything is working
well !

Thank you very much everybody for your help. Even if at the end my
problem was ... 'stupid' you learned me a lot and clarify my ideas
about component and configuration. I will follow your advices and I
think it will be faster for me not using components and
configuration

Thanks again and sorry to have keep you helping me for only a version
problem ...

Xavier