Re: Connecting "signed" to "std_logic_vector" ports.

Discussion in 'VHDL' started by KJ, Jul 31, 2010.

  1. KJ

    KJ Guest

    On Jul 30, 12:20 pm, rickman <> wrote:
    > On Jul 29, 6:43 am, Kolja Sulimma <> wrote:
    >
    > > On 29 Jul., 02:34, KJ <> wrote:

    >
    > > > Instead of this:
    > > >     Some_slv_sig <= std_logic_vector(Some_unsigned);
    > > > Do this
    > > >     Some_slv_sig <= std_ulogic_vector(Some_unsigned);

    >
    > > a package numeric_unresolved would be nice....

    >
    > > Kolja

    >
    > There is no reason why unresolved can't be added to numeric_std is
    > there?


    I don't think you could really *add* the unresolved types to
    numeric_std because to do so you would have to create new types other
    than 'unsigned' and 'signed' that are based on std_ulogic. Then of
    course you would have to get all of the synthesis and simulation
    vendors on board with the change before you could really use the new
    types. In the mean time, the 'least common denominator' rule will
    apply and everyone would continue to use the more supported current
    data types that are based on the resolved std_logic type...which would
    then kill all momentum for any of the vendors to support the change
    and the proposal would likely die quietly.

    If instead, numeric_std was simply changed from this...
    type UNSIGNED is array (NATURAL range <>) of STD_LOGIC;
    type SIGNED is array (NATURAL range <>) of STD_LOGIC;

    to this...
    type UNSIGNED is array (NATURAL range <>) of STD_ULOGIC;
    type SIGNED is array (NATURAL range <>) of STD_ULOGIC;

    Then the only ones the user community would have to beat on to get
    this implemented would be the simulation vendors. Synthesis vendors
    already flag multiple driver violations as a standard part of
    synthesis since they (for the most part) do not implement multiple net
    drivers.

    Changes to standard packages should of course not be taken lightly,
    but off the top of my head, I can't think of anyone that would be
    negatively impacted by this. I'll toss this out to the newsgroupies
    first to see if someone can come up with a use case where the change
    in the definition of 'unsigned' and 'signed' would negatively impact
    something. If not, then I'll submit it to the standards group for
    consideration...numeric_std was so close, they were only two letters
    short in the source code. Sooooo close.

    Kevin Jennings
    KJ, Jul 31, 2010
    #1
    1. Advertising

  2. KJ

    Andy Guest

    It would break existing code that used signed/unsigned like SLV, and
    needed the tri-state, multi-driver logic. Also, elements of unsigned
    would not be SL, with the same problem.

    Am I just dreaming, or wasn't there an effort to change the
    relationship between SLV and SULV such that they would become
    interchangeable subtypes like SUL and SL are? E.G. subtype SLV is
    resolved(SULV); or similar, with a new version of resolved() to match.
    It seems like the gotcha was that an element of such an SLV would no
    longer be SL, but SUL. But I thought they got around that.

    Andy
    Andy, Jul 31, 2010
    #2
    1. Advertising

  3. KJ

    KJ Guest

    On Jul 31, 1:50 pm, Andy <> wrote:
    > It would break existing code that used signed/unsigned like SLV, and
    > needed the tri-state, multi-driver logic. Also, elements of unsigned
    > would not be SL, with the same problem.
    >


    Actually, I intended my question more along the lines of if signed/
    unsigned were changed to be collections of std_ulogic rather than
    std_logic, how many would really notice/care? I understand that those
    who use signed/unsigned with multiple drivers would be affected...but
    how many of those cases are actually out there? So, do *you* use
    multiple drivers on signed/unsigned signals? Is that actually
    important to you?

    KJ
    KJ, Aug 3, 2010
    #3
  4. KJ

    Andy Guest

    On Aug 3, 8:40 am, KJ <> wrote:
    > On Jul 31, 1:50 pm, Andy <> wrote:
    >
    > > It would break existing code that used signed/unsigned like SLV, and
    > > needed the tri-state, multi-driver logic. Also, elements of unsigned
    > > would not be SL, with the same problem.

    >
    > Actually, I intended my question more along the lines of if signed/
    > unsigned were changed to be collections of std_ulogic rather than
    > std_logic, how many would really notice/care?  I understand that those
    > who use signed/unsigned with multiple drivers would be affected...but
    > how many of those cases are actually out there?  So, do *you* use
    > multiple drivers on signed/unsigned signals?  Is that actually
    > important to you?
    >
    > KJ


    Mostly in places where I have an inout port (or procedure argument) of
    a record type, and I need resolution functions to manage in and out
    elements more often than I actually use a bidirectional element. My
    test benches tend to have lots of procedures like read/write(bus,
    address, data)

    I have also used unsigned on tri-stated primary IOs of FPGAs (it is
    easy enough to convert them back to SLV if I need to use the gate
    level models).

    Internally, I have used them with a tri-state bus description, knowing
    full-well that the synthesis tool would convert them to muxes for me.
    The added benefit is that the synthesis tool can assume that the tri-
    state enables are mutually exclusive, which allows it to optimize the
    muxes. Sometimes it is just easier to describe an interface with a
    bus, than to create the mux and the plumbing for it. I don't usually
    do truly bi-directional busses, but sometimes...

    So, yes, I have used them in several areas.

    IMHO, changes to the language or standard packages must be backwards
    compatible (even though in rare cases in the past they have not been
    so), so that they don't break anyone's code, regardless of how common
    (or even "useful") a given usage is. The "prime directive" WRT changes
    to the standards should be "do no harm". If we need a different
    numeric_std-like package, so be it.

    Andy
    Andy, Aug 3, 2010
    #4
  5. KJ

    KJ Guest

    On Aug 3, 12:04 pm, Andy <> wrote:
    > On Aug 3, 8:40 am, KJ <> wrote:
    > IMHO, changes to the language or standard packages must be backwards
    > compatible (even though in rare cases in the past they have not been
    > so),


    Backwards compatibility should not be a 'must have'...although I
    certainly agree that it is something worth working for to get if you
    can. Examples of changes that are definitely more onerous to 'used to
    be working just fine' code were the changes to type 'FILE' and 'shared
    variables'.

    > so that they don't break anyone's code, regardless of how common
    > (or even "useful") a given usage is.


    I think the cost/benefit should be weighed although just how well one
    can weigh this with actual users is a bit of a question.

    > The "prime directive" WRT changes
    > to the standards should be "do no harm".


    'Do no harm' applies to doctors, not engineering standards. If
    something needs to be improved and is 'worth it' to the users then it
    should be improved. The definition of whether something is 'worth it'
    or not is subjective.

    > If we need a different
    > numeric_std-like package, so be it.
    >

    Maybe just use the fixed point package. The documentation says it
    uses std_logic as the base, but the actual code says std_ulogic.

    Thanks for your input on how you use/need multi-driver signed/unsigned

    Kevin Jennings
    KJ, Aug 5, 2010
    #5
    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. Jeremy Pyle
    Replies:
    3
    Views:
    52,618
    Mike Treseler
    Jun 28, 2003
  2. =?ISO-8859-15?Q?Fr=E9d=E9ric_Lochon?=

    connecting std_logic inout ports and std_logic_vector inout port

    =?ISO-8859-15?Q?Fr=E9d=E9ric_Lochon?=, Nov 6, 2007, in forum: VHDL
    Replies:
    3
    Views:
    843
  3. Thomas Rouam
    Replies:
    6
    Views:
    1,117
  4. mreister
    Replies:
    1
    Views:
    3,124
    mreister
    May 25, 2010
  5. Replies:
    11
    Views:
    719
Loading...

Share This Page