External name elaboration order

Discussion in 'VHDL' started by valtih1978, Nov 28, 2011.

  1. valtih1978

    valtih1978 Guest

    In "Designer's guide to VHDL", Chapter 18, I read:

    - BEGIN QUOTE -
    "We can use an external constant name (or an alias of such a name) in an
    expression, provided the constant has been elaborated and given a value
    by the time the expression is evaluated. In some cases, expressions are
    evaluated during elaboration of a design."

    "We can ensure this is the case by writing the part of the design that
    includes the constant declaration prior to the part of the design that
    contains the external constant name. VHDL’s elaboration rules specify
    that the design is elaborated in depth-first top-to-bottom order."

    "We now assemble the design and test bench in a top-level entity and
    architecture:

    architecture level of top is
    begin
    assert false report "Width = " & to_string(<<constant .top.duv.width
    : natural>>);
    duv : entity work.design(rtl);

    "The external constant name in the concurrent assertion statement, on
    the other hand, is not evaluated until the model is executed, by which
    time the model is completely elaborated. Thus, the external constant
    name is allowed to precede the instance of the design under test in
    which the constant is declared.

    - END QUOTE -

    It says that to be sure that referenced constant is evaluated prior to
    external name reference is evaluated, "declare the constant prior to the
    part of the design that contains the external constant name". But, in
    example we see the opposite: constant is declared in the instance below
    the assertion elaboration!

    Then, it reassures us that this is ok and develops this idea by denying it!

    "VHDL has a related rule regarding elaboration of a signal referenced by
    an external signal name. If such a name (or an alias of such a name) is
    used in a port map, the signal declaration must have been previously
    elaborated. The reason is that the hierarchy of signal nets and drivers
    is built during elaboration. If a signal used in a port map is not yet
    elaborated, the elaborator would have to revisit elaboration of that
    part of the design hierarchy once the signal declaration was
    encountered. In general, allowing such use of external signal names
    would make elaboration of signal nets indefinitely complicated. The rule
    preventing such use allows elaboration to proceed in a well-defined
    order, and is not onerous in practice."

    That is, they say that situation is the same and object, referenced in
    external name, must be elaborated before external name.


    alias DONE_SIG is <<signal DUT.DONE: BIT>>; -- Legal
    begin
    DUT: entity WORK.MY_DESIGN port map (s1, S2, S3);

    We do not want to re-elaborate the alias, once the signal declaration
    was encountered during instance elaboration. Right?

    After all, I could not understand if your VHDL example is correct or not.
     
    valtih1978, Nov 28, 2011
    #1
    1. Advertising

  2. valtih1978

    valtih1978 Guest

    >> That is, they say that situation is the same and object, referenced in
    >> external name, must be elaborated before external name.
    >>

    >
    > The paragraph you quote refers specifically to use of a signal
    > referenced by an external signal name *in a port map*.



    Yes, but it says that external constant evaluation during simulation "is
    related" to external signals in the port map during elaboration. do they
    say that external constant evaluation is treated in the same way as port
    map elaboration?


    Also, I could not understand why (and how) the signals, declared in the
    body of subinstance, are different from port map? I do not see essential
    difference between elaboration and evaluation.

    The elaboration establishes the references. Evaluation uses em. Indeed,
    you cannot use unestablished reference. But, in the same way, you cannot
    establish it either until referenced object is elaborated. How making
    exclusions for constants and port maps improves the situation?
     
    valtih1978, Dec 4, 2011
    #2
    1. Advertising

  3. valtih1978

    JimLewis Guest

    Hi Valtih1978 (interesting name),
    You don't quite have the terminology correct.

    The "external name" is the hierarchical reference:
    <<constant .top.duv.width : natural>>

    The constant, which is in the entity duv, is:
    constant WIDTH : natural := 5 ;


    Hence, the required order is:

    architecture level of top is
    begin
    -- instantiating DUV first makes objects declared in it elaborate
    first
    duv : entity work.design(rtl);

    -- now do external name references:
    assert false report "Width = " &
    to_string(<<constant .top.duv.width : natural>>);
    end level ;


    Best,
    Jim
     
    JimLewis, Dec 13, 2011
    #3
    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. Soren Kuula
    Replies:
    2
    Views:
    503
    Soren Kuula
    Feb 1, 2004
  2. Scott Allen
    Replies:
    8
    Views:
    10,949
    Scott Allen
    May 2, 2004
  3. cspoh
    Replies:
    0
    Views:
    252
    cspoh
    Jul 31, 2003
  4. Mellow Crow
    Replies:
    6
    Views:
    420
    Richard Cornford
    Nov 4, 2005
  5. valtih1978

    Separate elaboration and parsing

    valtih1978, Apr 24, 2014, in forum: VHDL
    Replies:
    6
    Views:
    124
    valtih1978
    Apr 26, 2014
Loading...

Share This Page