Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Modelsim : Problem with generics

Reply
Thread Tools

Modelsim : Problem with generics

 
 
XSterna
Guest
Posts: n/a
 
      07-17-2008
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
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      07-17-2008
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
 
Reply With Quote
 
 
 
 
XSterna
Guest
Posts: n/a
 
      07-17-2008
On 17 juil, 22:14, Mike Treseler <(E-Mail Removed)> 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
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      07-18-2008

"XSterna" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 17 juil, 22:14, Mike Treseler <(E-Mail Removed)> 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


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

In any case, if you change the default values for the generics (or other
inputs) in the entity those new values will be used (after you compile it).

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 usually just directly instantiate the entity, but I use generics a lot and
default values are properly assigned if I don't override them in the map so
I doubt that it's a Modelsim problem...take a look for those component
definitions, I'll bet that's where the problem is.

KJ


 
Reply With Quote
 
Mark McDougall
Guest
Posts: n/a
 
      07-18-2008
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
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      07-18-2008
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
 
Reply With Quote
 
XSterna
Guest
Posts: n/a
 
      07-18-2008
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" <(E-Mail Removed)> 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 <(E-Mail Removed)> 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 <(E-Mail Removed)> 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
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      07-18-2008
On Jul 18, 5:29*am, XSterna <(E-Mail Removed)> 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" <(E-Mail Removed)> 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 <(E-Mail Removed)> 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=2
# Time: 0 ns Iteration: 0 Instance: /tb_foo/u2
# ** Note: :tb_foo:u1=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
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      07-18-2008
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/sear..._bit+component

-- Mike Treseler
 
Reply With Quote
 
XSterna
Guest
Posts: n/a
 
      07-18-2008
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 <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
generics depending on generics Soul VHDL 0 02-02-2009 09:14 AM
problem with modelsim Torsten Bitterlich VHDL 3 04-24-2008 10:52 PM
Can't convert a generics list of objects into a generics list ofinterfaces Juergen Berchtel Java 1 05-20-2005 02:07 PM
tcl, modelsim and vhdl generics Riyaz VHDL 1 04-23-2004 08:05 PM
Yet another modelsim problem Thomas VHDL 1 08-14-2003 06:14 AM



Advertisments