using buffer mode ports

Discussion in 'VHDL' started by Valentin Tihomirov, Nov 8, 2003.

  1. I experiance a difficulty controlling out port from within an instance. I
    think the port should be in *buffer* mode. However, my analyzer throws this
    message:
    " Actual of mode 'inout' can not be assigned to formal <signal> of mode
    'buffer' "

    I have took a look into FAQ; it describes my situation:
    http://vhdl.org/vi/comp.lang.vhdl/FAQ1.html#buffer_ports
    But I cannot conclude from it what is a typical pracice in VHDL for the case
    :-(

    There is a *linkage* mode which is not described in tutorials I wanted to
    know when to use.
    Valentin Tihomirov, Nov 8, 2003
    #1
    1. Advertising

  2. > I experiance a difficulty controlling out port from within an instance. I
    > think the port should be in *buffer* mode. However, my analyzer throws
    > this message:
    > " Actual of mode 'inout' can not be assigned to formal <signal> of mode
    > 'buffer' "


    Personally I try not to use inout as a port type unless it's actually a
    tristatable bus. Throughout my design I'll use type BUFFER, and at top
    level I'll use an intermediate signal to connect it to a port OUT. An
    alternative is to always use internal signals to use the internal value of
    a signal, and then connect it to a port of type OUT.

    If you insist on using INOUT in combination with BUFFER, just use an
    intermediate signal, and connect that to the BUFFER port. Something like:

    label_l: component_name
    PORT MAP
    (
    a => a_int -- a of type INOUT, a_int an internal signal
    );

    a_buf <= a_int; -- connect a_int to buffer port a_buf, where a_buf is
    defined as a buffer in the entity

    Regards,

    Pieter Hulshoff
    Pieter Hulshoff, Nov 8, 2003
    #2
    1. Advertising

  3. Whether mode of a port is out or buffer you use intermediate signal to
    update it. What is ther reason to use *buffer* at all? Why does LRM prohibit
    updating buffer from instance scope?
    Valentin Tihomirov, Nov 8, 2003
    #3
  4. > Whether mode of a port is out or buffer you use intermediate signal to
    > update it. What is ther reason to use *buffer* at all? Why does LRM
    > prohibit updating buffer from instance scope?


    No, I normally use port BUFFER to allow me to use the internal value of the
    output signal. The construction I gave you is one I'd never use, but then
    again I don't try to connect a port of type INOUT to one of port BUFFER.
    From your words I gathered that was what you were trying to do. If I
    misunderstood, please post some examples of your code so that I may
    understand your problem and help you to find a proper solution.

    Regards,

    Pieter Hulshoff
    Pieter Hulshoff, Nov 8, 2003
    #4
  5. I've already found a solution. I refused using buffer mode, cos I need
    intermediate signal anyway.

    entity E port (I: in bit; O: out: std_logic) end E;

    architecture EXAMPLE of E is
    signal O_INTERMEDIATE: std_logic;
    begin
    unit: entity work.X port map(I, O_INTERMEDIATE);
    O <= O_INTERMEDIATE;
    end EXAMPLE;

    This works the same when 'O' port is either in out or buffer mode.

    But I still do not understand what is the reason to use *buffer* mode? Why
    does LRM prohibit updating buffer port from instance's scope? I think if
    have a right to update port's value (a buffer mode) within my architecture
    then I can do it wherever I like.
    Valentin Tihomirov, Nov 8, 2003
    #5
  6. > But I still do not understand what is the reason to use *buffer* mode? Why
    > does LRM prohibit updating buffer port from instance's scope? I think if
    > have a right to update port's value (a buffer mode) within my architecture
    > then I can do it wherever I like.


    You have to look at mode BUFFER as a wire with a split: one end goes back
    into your architecture (so it can be used for logic), and the other goes
    through a buffer out of the block. Anything you do outside the block to the
    signal should not influence the value inside the block, because it is
    stopped by the buffer (some exceptions apply of course; short-circuit or
    high voltage should still have some interesting effects:).

    Regards,

    Pieter Hulshoff
    Pieter Hulshoff, Nov 9, 2003
    #6

  7. > You have to look at mode BUFFER as a wire with a split: one end goes back
    > into your architecture (so it can be used for logic), and the other goes
    > through a buffer out of the block. Anything you do outside the block to

    the

    Yes, I have the same image. But it is not clear due to the details I do not
    understand.
    1. Internal buffers can be split without any special declarations. The
    only thing I suppose one can buffer outgoing signal is to allow for its
    greater load. However, VHDL is not powerful enaught and not intended to
    worry about technological issues, it is VHDL is simulation, RTL and logic
    specification language. I do not talk about tricks with controlling
    placement from VHDL, this is tool specific and is not putpose of the
    language. So, buffer incurring as a task of implementing tool.




    > ... Anything you do outside the block to the
    > signal should not influence the value inside the block, because it is
    > stopped by the buffer (some exceptions apply of course; short-circuit or
    > high voltage should still have some interesting effects:).



    2. IMO, *outside* the block means an upper level of hierarchy, i.e.
    "parent" of the block. And vise versa, the notion *inside* or within *scope*
    of a block does mean that a feature is implemented by any stuctural element
    of the block. In my interpretation, signal can be updated by a statement or
    any of its sub-modules. Therefore, it is not logical that a statement can
    update a port (out or buffe rmode) but instance cannot.
    Valentin Tihomirov, Nov 9, 2003
    #7
  8. > I do not talk about tricks with controlling
    > placement from VHDL, this is tool specific and is not putpose of the
    > language. So, buffer incurring as a task of implementing tool.


    *nod*, and it will be. I just explained how to envision the VHDL. How it
    will be synthesized is a totally different matter.

    > 2. IMO, *outside* the block means an upper level of hierarchy, i.e.
    > "parent" of the block.

    <snip>
    > Therefore, it is not
    > logical that a statement can update a port (out or buffe rmode) but
    > instance cannot.


    From what is synthesized I agree with you; it should be possible to do so.
    From a language point of view however it cannot. In the language it
    represents a buffered output (even though it will probably not be
    synthesized that way), and as such the language will not allow you to drive
    the value from outside that hierarchy level. That's even aside from the
    tons of trouble you'd get yourself into with multiple drivers on a single
    signal if the language _would_ allow it.

    Regards,

    Pieter Hulshoff
    Pieter Hulshoff, Nov 9, 2003
    #8
  9. Pieter Hulshoff wrote:
    >
    >
    > You have to look at mode BUFFER as a wire with a split: one end goes back
    > into your architecture (so it can be used for logic), and the other goes
    > through a buffer out of the block. Anything you do outside the block to the
    > signal should not influence the value inside the block, because it is
    > stopped by the buffer (some exceptions apply of course; short-circuit or
    > high voltage should still have some interesting effects:).
    >


    If I may add to the confusion. ;-)

    There isn't anything you can do outside the block, because any actual
    associated with a formal buffer port may have at most one source (LRM 93,
    page 7, line 107).

    For normal (non tri-state) outputs this is exactly what you want. That's
    why I always use buffer for normal outputs. In contrast to an output with
    mode out, an output with mode buffer may be read internally. Having said that,
    in VHDL93 you can read an output with mode out internally by using the 'driving
    attribute (which is a kludge, IMO).

    There's only one disadvantage with the use of buffer: if you start using it,
    you'll have to be consistant. An instantiated module with a mode out output may
    not drive the output of the instantiating module if that output is mode buffer.

    Finally: the word buffer has nothing to do with actually placing buffers
    during synthesis.

    Paul.
    Paul Uiterlinden, Nov 10, 2003
    #9
  10. Valentin Tihomirov

    MM Guest

    "Paul Uiterlinden" <> wrote in message
    news:3faf5f9c$0$58712$4all.nl...
    > There's only one disadvantage with the use of buffer: if you start using

    it,
    > you'll have to be consistant. An instantiated module with a mode out

    output may
    > not drive the output of the instantiating module if that output is mode

    buffer.

    I found that there is another disadvantage. Suppose you want to use a
    post-par VHDL model for timing simulation with the same test bench you used
    for functional simulation. The model will not have buffer type ports since
    this spec will have been lost somewhere in the synthesis/implementation
    phase and you will have to change your module interface in the test bench to
    make it work.

    /Mikhail
    MM, Nov 10, 2003
    #10
  11. MM wrote:


    >> There's only one disadvantage with the use of buffer:

    >
    > I found that there is another disadvantage. Suppose you want to use
    > a post-par VHDL model for timing simulation with the same test bench
    > you used for functional simulation. The model will not have buffer
    > type ports since this spec will have been lost somewhere in the
    > synthesis/implementation phase and you will have to change your
    > module interface in the test bench to make it work.


    OK, you're right. In that case I would make an exception for the
    top-level: use mode out. This of course means some intermediate
    signals in the top level architecture though.

    Paul.
    Paul Uiterlinden, Nov 10, 2003
    #11
    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. Anand P Paralkar

    Buffer Mode Ports

    Anand P Paralkar, Nov 24, 2003, in forum: VHDL
    Replies:
    1
    Views:
    576
    Mike Treseler
    Nov 24, 2003
  2. Winston Smith

    BUFFER mode ports

    Winston Smith, Feb 2, 2005, in forum: VHDL
    Replies:
    12
    Views:
    13,905
    Brian Drummond
    Feb 13, 2005
  3. John J Lee
    Replies:
    3
    Views:
    456
    bruno at modulix
    Dec 1, 2005
  4. Edward Loper
    Replies:
    0
    Views:
    445
    Edward Loper
    Aug 7, 2007
  5. mreister
    Replies:
    1
    Views:
    3,112
    mreister
    May 25, 2010
Loading...

Share This Page