Modelsim : Problem with generics

Discussion in 'VHDL' started by XSterna, Jul 17, 2008.

  1. XSterna

    XSterna Guest

    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
    XSterna, Jul 17, 2008
    #1
    1. Advertising

  2. 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
    Mike Treseler, Jul 17, 2008
    #2
    1. Advertising

  3. XSterna

    XSterna Guest

    On 17 juil, 22:14, Mike Treseler <> 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, Jul 18, 2008
    #3
  4. XSterna

    KJ Guest

    "XSterna" <> wrote in message
    news:...
    > On 17 juil, 22:14, Mike Treseler <> 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
    KJ, Jul 18, 2008
    #4
  5. 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
    Mark McDougall, Jul 18, 2008
    #5
  6. 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
    Mike Treseler, Jul 18, 2008
    #6
  7. XSterna

    XSterna Guest

    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" <> 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 <> 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 <> 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
    XSterna, Jul 18, 2008
    #7
  8. XSterna

    KJ Guest

    On Jul 18, 5:29 am, XSterna <> 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" <> 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 <> 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
    KJ, Jul 18, 2008
    #8
  9. Mike Treseler, Jul 18, 2008
    #9
  10. XSterna

    XSterna Guest

    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 <> 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
    XSterna, Jul 18, 2008
    #10
  11. XSterna

    KJ Guest

    On Jul 18, 9:51 am, XSterna <> 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
    KJ, Jul 18, 2008
    #11
  12. XSterna

    HT-Lab Guest

    "XSterna" <> wrote in message
    news:...
    > 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 !


    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,

    Hans
    www.ht-lab.com
    HT-Lab, Jul 18, 2008
    #12

  13. >> 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
    Kevin Neilson, Jul 18, 2008
    #13
  14. XSterna

    XSterna Guest

    On 18 juil, 17:37, KJ <> 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, Jul 19, 2008
    #14
  15. XSterna

    XSterna Guest

    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
    XSterna, Jul 19, 2008
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Torsten Bitterlich

    problem with modelsim

    Torsten Bitterlich, Aug 3, 2003, in forum: VHDL
    Replies:
    3
    Views:
    3,222
    agustinmarquez
    Apr 24, 2008
  2. Thomas

    Yet another modelsim problem

    Thomas, Aug 12, 2003, in forum: VHDL
    Replies:
    1
    Views:
    1,320
    K Mussatt
    Aug 14, 2003
  3. Riyaz
    Replies:
    1
    Views:
    1,035
    Jonathan Bromley
    Apr 23, 2004
  4. Juergen Berchtel
    Replies:
    1
    Views:
    5,991
    John C. Bollinger
    May 20, 2005
  5. Soul
    Replies:
    0
    Views:
    519
Loading...

Share This Page