Using OPEN in port map

Discussion in 'VHDL' started by rickman, Jul 17, 2009.

  1. rickman

    rickman Guest

    I was reading in Ben Cohen's book that OPEN has some restrictions.
    One is that it can not be used with a specified set of items in an
    array when the other items are mapped to other signals. Here is an
    example.

    Mul: multiply
    PORT MAP (
    SysClk => SysClk, -- System clock, 12.288 MHz?
    Start => Start, -- Load multiplican and init result
    Multiplicand => LinDat,
    Multiplier => std_logic_vector(AudioGain),
    Product(ProdHigh downto ProdHigh - MulOut'high) => MulOut,
    Product(ProdHigh - MulOut'high - 1 downto 0) => OPEN,
    Done => Done
    );

    According to Ben Cohen book, the product can not be split this way
    using OPEN. When I tried it with Synplicity it seems to accept this
    syntax. Ben's book is a bit older and refers to the '93 standard. I
    believe there is a newer VHDL standard, 200x. Is this something that
    has changed since '93 or is the Synplicity tool just being
    magnanimous? Should I change it so that it will work with other tools
    or do most tools accept this?

    Rick

    PS Don't ask me the name of the book, I don't have it with me. It was
    a larger book and consisted of many examples of specific aspects of
    the language rather than a general explanation of the language. I
    like paper books, but sometimes I like the portability of e-books
    (pdf).
    rickman, Jul 17, 2009
    #1
    1. Advertising

  2. rickman

    KJ Guest

    On Jul 16, 7:19 pm, rickman <> wrote:

    > Product(ProdHigh downto ProdHigh - MulOut'high) => MulOut,
    > Product(ProdHigh - MulOut'high - 1 downto 0) => OPEN,


    > According to Ben Cohen book, the product can not be split this way
    > using OPEN.  When I tried it with Synplicity it seems to accept this
    > syntax.  Ben's book is a bit older and refers to the '93 standard.  I
    > believe there is a newer VHDL standard, 200x.  Is this something that
    > has changed since '93 or is the Synplicity tool just being
    > magnanimous?  Should I change it so that it will work with other tools
    > or do most tools accept this?
    >


    Modelsim 6.4 (which is not the latest/greatest) reports the following
    (compiled with either VHDL '93 or '02)
    Error: Formal "xyz" must not be associated with OPEN when subelements
    are associated individually

    On the other hand, this particular item is something that I submitted
    to the VHDL standards group a few years back and was accepted at that
    time as a 'good' idea...maybe it made it into VHDL '08...if not theirs
    always VHDL 201x.

    Kevin Jennings
    KJ, Jul 17, 2009
    #2
    1. Advertising

  3. rickman

    JimLewis Guest

    Unfortunately it is illegal (still) in 2008 revision.

    Jim
    SynthWorks VHDL Training
    JimLewis, Jul 21, 2009
    #3
  4. JimLewis wrote:

    > Unfortunately it is illegal (still) in 2008 revision.


    And can anyone explain to me - why????

    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 21, 2009
    #4
  5. rickman

    JimLewis Guest

    > On the other hand, this particular item is something that I submitted
    > to the VHDL standards group a few years back and was accepted at that
    > time as a 'good' idea...maybe it made it into VHDL '08...if not theirs
    > always VHDL 201x.


    Kevin,
    Do you have a bug ID for it? I was looking through the bugzilla
    database and could not find it.

    Jim
    JimLewis, Jul 28, 2009
    #5
  6. rickman

    KJ Guest

    On Jul 28, 3:00 pm, JimLewis <> wrote:
    > > On the other hand, this particular item is something that I submitted
    > > to the VHDL standards group a few years back and was accepted at that
    > > time as a 'good' idea...maybe it made it into VHDL '08...if not theirs
    > > always VHDL 201x.

    >
    > Kevin,
    > Do you have a bug ID for it?  I was looking through the bugzilla
    > database and could not find it.
    >
    > Jim


    Jim,

    No I don't have a bug ID. I also haven't been able to locate anything
    specific but I'm pretty darn sure I went through the eda-stds.org link
    (http://www.eda-stds.org/vasg/#Enhancements) to submit the request.
    Based on other bits and pieces, I believe the request was submitted in
    2005.

    Should another one be submitted to cover this case? FYI, as I
    mentioned back in 2005, the place where I think opens in port maps are
    most handy is when the VHDL code is generated by a CAD system and
    represent a PCBA netlist. When designing a board, it certainly is the
    case where you can legally have unconnected pins and those pins might
    happen to be bits of some 'bus' of related pins. Back in 2005, I had
    a device which happened to have a 24 bit data bus of which I was only
    using 16 bits and the part had no requirement to drive unused pins on
    that bus.

    On a side note, I also submitted a request for a totally different
    feature back in June 2008. On that one I got a reply back that said
    it had been assigned number 2132. The Bugzilla.mentor.com site says
    that bug #2132 does not exist so I have no idea what number that
    request have been refiled under or if that request has been lost or
    reached some other disposition. If you need any more info, I can
    forward you what I have on that one.

    Kevin Jennings
    KJ, Jul 30, 2009
    #6
  7. On Jul 30, 9:31 am, KJ <> wrote:
    > On Jul 28, 3:00 pm, JimLewis <> wrote:
    >
    > > > On the other hand, this particular item is something that I submitted
    > > > to the VHDL standards group a few years back and was accepted at that
    > > > time as a 'good' idea...maybe it made it into VHDL '08...if not theirs
    > > > always VHDL 201x.

    >
    > > Kevin,
    > > Do you have a bug ID for it?  I was looking through the bugzilla
    > > database and could not find it.

    >
    > > Jim

    >
    > Jim,
    >
    > No I don't have a bug ID.  I also haven't been able to locate anything
    > specific but I'm pretty darn sure I went through the eda-stds.org link
    > (http://www.eda-stds.org/vasg/#Enhancements) to submit the request.
    > Based on other bits and pieces, I believe the request was submitted in
    > 2005.
    >
    > Should another one be submitted to cover this case?  FYI, as I
    > mentioned back in 2005, the place where I think opens in port maps are
    > most handy is when the VHDL code is generated by a CAD system and
    > represent a PCBA netlist.  When designing a board, it certainly is the
    > case where you can legally have unconnected pins and those pins might
    > happen to be bits of some 'bus' of related pins.  Back in 2005, I had
    > a device which happened to have a 24 bit data bus of which I was only
    > using 16 bits and the part had no requirement to drive unused pins on
    > that bus.
    >
    > On a side note, I also submitted a request for a totally different
    > feature back in June 2008.  On that one I got a reply back that said
    > it had been assigned number 2132.  The Bugzilla.mentor.com site says
    > that bug #2132 does not exist so I have no idea what number that
    > request have been refiled under or if that request has been lost or
    > reached some other disposition.  If you need any more info, I can
    > forward you what I have on that one.
    >
    > Kevin Jennings


    Hi KJ,
    I think you are not only right on the output pins, but also right on
    the input pins.

    When a module is shared by several upper modules, there is a
    possibility that each upper module may have specific input pins other
    upper modules don't share, and when each upper module calls this
    module, they can leave unused input signals in OPEN state. When VHDL
    compiler meets input signals with open connection, reports an fatal
    error.

    This way more upper modules can share a based module with different
    number of input signals. Currently I have to supply DUMMY inputs which
    are ineffective in production, and non-productive in coding.

    When an input signal is connected to "OPEN', it means this input is
    never used in this module, and if used, it is a fatal error.

    It is a much clearer and clever idea to permit to use "OPEN" for input
    signals to a module too.

    Weng
    Weng Tianxiang, Jul 30, 2009
    #7
  8. rickman

    rickman Guest

    On Jul 17, 4:37 am, Alan Fitch <> wrote:
    > rickman wrote:
    >
    > <snip>
    >
    >
    >
    >
    >
    > >   Mul: multiply
    > >    PORT MAP (
    > >      SysClk                => SysClk,  -- System clock, 12.288 MHz?
    > >      Start                 => Start,    -- Load multiplican and init result
    > >      Multiplicand  => LinDat,
    > >      Multiplier    => std_logic_vector(AudioGain),
    > >      Product(ProdHigh downto ProdHigh - MulOut'high)       => MulOut,
    > >      Product(ProdHigh - MulOut'high - 1 downto 0)  => OPEN,
    > >      Done                  => Done
    > >    );

    >
    > > According to Ben Cohen book, the product can not be split this way
    > > using OPEN.  When I tried it with Synplicity it seems to accept this
    > > syntax.  Ben's book is a bit older and refers to the '93 standard.  I
    > > believe there is a newer VHDL standard, 200x.  Is this something that
    > > has changed since '93 or is the Synplicity tool just being
    > > magnanimous?  Should I change it so that it will work with other tools
    > > or do most tools accept this?

    >
    > > Rick

    >
    > Hi Rick,
    >    it was legal to do that (split an array up on the left of the
    > association and leave parts of it open) in VHDL 87. It was made illegal
    > in VHDL 93, i.e either the whole array may be left unconnected, or every
    > element of the array must be associated,
    >
    > regards
    > Alan


    Hi Alan,

    I still have not had a chance (read that as "remembered") to look this
    up in Ben's book. But I am surprised that it would have been legal in
    '87 and made illegal in the '93 standard, unless there was some reason
    for it. Is there any complication to the tools that allowing this use
    of OPEN would create? I am not really familiar with the innards of
    how the tools work, but I believe things like the widths of busses are
    defined in an initial "compile" and then the modules are used in the
    "elaborate" phase. It might be an issue where a given module needs to
    be compiled once and then used in many places. I think the use of
    OPEN would cause the associated inputs and outputs to be dropped which
    can eliminate logic. Clearly you can't use a common module if
    different uses have different logic.

    Is that why using OPEN in this way was made illegal?

    Rick
    rickman, Jul 30, 2009
    #8
  9. rickman

    KJ Guest

    On Jul 30, 4:09 pm, Weng Tianxiang <> wrote:
    > On Jul 30, 9:31 am, KJ <> wrote:
    > Hi KJ,
    > I think you are not only right on the output pins, but also right on
    > the input pins.
    >


    I was talking about inputs, outputs and inouts.

    > When a module is shared by several upper modules, there is a
    > possibility that each upper module may have specific input pins other
    > upper modules don't share, and when each upper module calls this
    > module, they can leave unused input signals in OPEN state. When VHDL
    > compiler meets input signals with open connection, reports an fatal
    > error.
    >


    Input pins in a module that are not part of a bus and that are not
    used in certain applications simply need to have an initializer
    applied to them.

    xyz: in std_ulogic := '0';

    If the user then does not connect up anything to 'xyz' it will be
    treated as a '0' since that's what the initializer sets it to...no
    errors. The problem comes in when 'xyz' is a *vector* and not all of
    the bits in the vector are used in certain applications.

    > This way more upper modules can share a based module with different
    > number of input signals. Currently I have to supply DUMMY inputs which
    > are ineffective in production, and non-productive in coding.
    >

    <snip>
    > It is a much clearer and clever idea to permit to use "OPEN" for input
    > signals to a module too.
    >


    If you're talking about scalars and not vectors, then look into using
    initializers on the input pins instead.

    KJ
    KJ, Jul 31, 2009
    #9
  10. rickman

    Andy Guest

    Couldn't you use an unconstrained vector port? Of course whatever bits
    you do want to hook up must be contiguous. And it does not help with
    record types.

    And if you did allow open portions of vectored port associations (in
    some past/future version) would that work with unconstrained ports?
    Maybe that's where it ran afoul in the first place.

    Andy
    Andy, Jul 31, 2009
    #10
  11. rickman

    KJ Guest

    On Jul 31, 11:42 am, Andy <> wrote:

    > Couldn't you use an unconstrained vector port?


    Not when you don't have control of the design that you're interfacing
    with that you also don't happen to want to connect up all the I/O to.
    The specific example that I gave earlier in the thread is...

    "When designing a board, it certainly is the case where you can
    legally have unconnected pins and those pins might happen to be bits
    of some 'bus' of related pins. Back in 2005, I had a device which
    happened to have a 24 bit data bus of which I was only using 16 bits
    and the part had no requirement to drive unused pins on that bus."

    Since the VHDL file for the netlist for the PCBA is written by the
    schematic capture ECAD tool, I don't have direct control of that VHDL
    file other than to modify something on the schematic for the board.
    One work around would be to make one pin nets for each of the pins
    that are 'unused'. Now the ECAD tool will write out a netlist with
    everything attached...the downside here is that when doing board
    design, 'one pin nets' are usually a form of design error.
    Intentionally adding noise to this check by creating one pin nets just
    to satisfy a simulation tool is counter-productive. There are other
    work arounds, with their own particular disadvantages as well.

    One could also be further removed from the PCBA design in that maybe
    you don't have design control of the PCBA, you're simply the recipient
    of the design in which case the work around is manual edits to the
    VHDL netlist for the board.

    > And it does not help with record types.
    >


    Record types don't need any help, they can be defaulted by the usual
    method of supplying an initializer on the entity. The problem is with
    vectors (of any type).

    > And if you did allow open portions of vectored port associations (in
    > some past/future version) would that work with unconstrained ports?
    > Maybe that's where it ran afoul in the first place.
    >


    Maybe...but in the process of making this change they created a
    situation where a common hardware design situation (i.e. unconnected
    pins on a chip) can not be modelled. Sometimes some may forget that
    the 'H' in VHDL stands for hardware.

    Kevin Jennings
    KJ, Aug 1, 2009
    #11
  12. rickman

    Andy Guest

    On Jul 31, 8:07 pm, KJ <> wrote:
    > On Jul 31, 11:42 am, Andy <> wrote:
    >
    > > Couldn't you use an unconstrained vector port?

    >
    > Not when you don't have control of the design that you're interfacing
    > with that you also don't happen to want to connect up all the I/O to.
    > The specific example that I gave earlier in the thread is...
    >
    > "When designing a board, it certainly is the case where you can
    > legally have unconnected pins and those pins might happen to be bits
    > of some 'bus' of related pins.  Back in 2005, I had a device which
    > happened to have a 24 bit data bus of which I was only using 16 bits
    > and the part had no requirement to drive unused pins on that bus."
    >
    > Since the VHDL file for the netlist for the PCBA is written by the
    > schematic capture ECAD tool, I don't have direct control of that VHDL
    > file other than to modify something on the schematic for the board.
    > One work around would be to make one pin nets for each of the pins
    > that are 'unused'.  Now the ECAD tool will write out a netlist with
    > everything attached...the downside here is that when doing board
    > design, 'one pin nets' are usually a form of design error.
    > Intentionally adding noise to this check by creating one pin nets just
    > to satisfy a simulation tool is counter-productive.  There are other
    > work arounds, with their own particular disadvantages as well.
    >
    > One could also be further removed from the PCBA design in that maybe
    > you don't have design control of the PCBA, you're simply the recipient
    > of the design in which case the work around is manual edits to the
    > VHDL netlist for the board.
    >
    > > And it does not help with record types.

    >
    > Record types don't need any help, they can be defaulted by the usual
    > method of supplying an initializer on the entity.  The problem is with
    > vectors (of any type).
    >
    > > And if you did allow open portions of vectored port associations (in
    > > some past/future version) would that work with unconstrained ports?
    > > Maybe that's where it ran afoul in the first place.

    >
    > Maybe...but in the process of making this change they created a
    > situation where a common hardware design situation (i.e. unconnected
    > pins on a chip) can not be modelled.  Sometimes some may forget that
    > the 'H' in VHDL stands for hardware.
    >
    > Kevin Jennings


    Very good points, thanks. I was thinking of entities for custom stuff
    that I wrote. There's usually other hacking involved anytime I've
    tried to use a VHDL netlist of a board for anything.

    Would it be legal to associate (others => 'Z') to those portions of
    the port, instead of OPEN? It's been a while since I had to do
    something like that.

    Preference for resolved signals with tri-state values came about in
    '93 I believe. IINM, it was at that time that guarded blocks and
    disconnects were deprecated(?). Maybe the OPEN binding was abandoned
    in favor of tri-state literals?

    Andy
    Andy, Aug 1, 2009
    #12
  13. rickman

    JimLewis Guest

    JimLewis, Aug 6, 2009
    #13
  14. rickman

    KJ Guest

    On Aug 6, 1:37 pm, JimLewis <> wrote:
    > Kevin,
    > It is here:https://bugzilla.mentor.com/show_bug.cgi?id=240
    >
    > Note it is IR 2132, however it is bugzilla issue 240.
    >
    > Best,
    > Jim


    Bug #275 has been submitted as an enhancement to the language to allow
    for opens on vector subelements.

    Kevin Jennings
    KJ, Aug 10, 2009
    #14
    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. John T. Goodman

    Overhead of 4-port over 2-port SRAM

    John T. Goodman, Jan 25, 2005, in forum: VHDL
    Replies:
    0
    Views:
    590
    John T. Goodman
    Jan 25, 2005
  2. Erik Arner
    Replies:
    0
    Views:
    1,302
    Erik Arner
    Nov 2, 2004
  3. kl
    Replies:
    7
    Views:
    1,274
    James Kanze
    Jan 1, 2008
  4. revanthb3000

    Using port map in a process

    revanthb3000, Nov 10, 2011, in forum: VHDL
    Replies:
    1
    Views:
    1,546
    jeppe
    Nov 11, 2011
  5. robstalker

    error using aggregates in port map

    robstalker, Nov 15, 2011, in forum: VHDL
    Replies:
    0
    Views:
    1,087
    robstalker
    Nov 15, 2011
Loading...

Share This Page