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.
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 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.
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).
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
