Resolved vs. Unresolved standard logic, and when to get away with using each

Discussion in 'VHDL' started by gsteemso, Mar 7, 2013.

  1. gsteemso

    gsteemso Guest

    Hi all,

    I am teaching myself VHDL, and have reached the limits of Ashenden's
    "Student's Guide to VHDL 2nd ed." It is good at introductory concepts
    but falls short soon thereafter; now that I am trying to look up
    aspects of the language to implement a real design, I keep finding that
    it glosses over the details I need.

    Research online has revealed that resolved logic allows you to drive a
    signal from multiple sources, as with the data bus in the average
    computer, and unresolved logic is considered better for simulation
    because (a) it's faster and (b) it will complain about multiple drivers
    when you don't want them. Is that accurate?

    Unfortunately, the same research reveals that you end up with a hideous
    stew of type conversions when you intermix them in the same design,
    unless you have godlike powers of foresight. I see that VHDL-2008
    allows them to mix more easily, but I rather suspect there must be
    pitfalls to that semantic change that I have not found any discussion
    of yet. Will incautiously written code silently permit conflicting
    signals if some of them are declared resolved and some are not?

    I have other questions about the language, but I will post them
    separately so as not to muddy the waters too much.

    gsteemso
    gsteemso, Mar 7, 2013
    #1
    1. Advertising

  2. gsteemso

    Robert Miles Guest

    Re: Resolved vs. Unresolved standard logic, and when to get away withusing each

    I suspect that resolved logic is for buses with more than one tristate driver, and unresolved logic is for signals with only one driver, not tristate type.

    For ASIC or FPGA design, buses with more than one tristate driver are usually best reserved for connections off that ASIC or FPGA, and then only if they need to allow driving from multiple sources.
    Robert Miles, Mar 7, 2013
    #2
    1. Advertising

  3. gsteemso <> writes:

    > Hi all,
    >
    > I am teaching myself VHDL, and have reached the limits of Ashenden's "Student's
    > Guide to VHDL 2nd ed." It is good at introductory concepts but falls short soon
    > thereafter; now that I am trying to look up aspects of the language to implement
    > a real design, I keep finding that it glosses over the details I need.
    >


    Really? I keep referring back to it to *find* the details I haven't used for a while!

    > Research online has revealed that resolved logic allows you to drive a signal
    > from multiple sources, as with the data bus in the average computer, and
    > unresolved logic is considered better for simulation because (a) it's faster and
    > (b) it will complain about multiple drivers when you don't want them. Is that
    > accurate?


    Yes

    >
    > Unfortunately, the same research reveals that you end up with a hideous stew of
    > type conversions when you intermix them in the same design, unless you have
    > godlike powers of foresight.


    No foresight required: just use the unresolved type throughout
    - except on the top-level IOs where you need to tristate the output.

    Then, (IIRC) the only time it's a pain is (pre 2008) when you have to
    use an IP core which uses resolved vectors. Then an intermediate signal
    is required.

    And if you want to do a post-synth/PAR simulation as the model they
    generate will be resolved types on the IOs. A quick wrapper can fix
    that easily though. Or you can choose to use resolved types throughout
    your top-level as a half-way house.

    > I see that VHDL-2008 allows them to mix more easily, but I rather
    > suspect there must be pitfalls to that semantic change that I have not
    > found any discussion of yet. Will incautiously written code silently
    > permit conflicting signals if some of them are declared resolved and
    > some are not?


    I'd be surprised, I believe all that happens is an implicit resolved
    signal is formed for the connection of an unresolved signal to a
    resolved one.

    Cheers,
    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.co.uk/capabilities/39-electronic-hardware
    Martin Thompson, Mar 7, 2013
    #3
  4. gsteemso

    KJ Guest

    Re: Resolved vs. Unresolved standard logic, and when to get away withusing each

    On Thursday, March 7, 2013 6:45:58 AM UTC-5, Martin Thompson wrote:
    > Then, (IIRC) the only time it's a pain is (pre 2008) when you have to use an
    > IP core which uses resolved vectors. Then an intermediate signal is required.


    Minor point...You can put the conversion right in the port map without having to create any intermediate signals.

    DUT : ip_core_with_slv port map(
    std_logic_vector(a) => my_sulv_a,
    b => std_ulogic_vector(my_sulv_b));

    Kevin Jennings
    KJ, Mar 7, 2013
    #4
  5. gsteemso

    valtih1978 Guest

    Re: Resolved vs. Unresolved standard logic, and when to get awaywith using each

    On 7.03.2013 14:16, KJ wrote:
    > oint...You can put the conversion right in the port map without having to create any intermediate signals.


    Thanks, it might be very important for the clock lines.
    valtih1978, Mar 7, 2013
    #5
  6. gsteemso

    Andy Guest

    Re: Resolved vs. Unresolved standard logic, and when to get away withusing each

    On Thursday, March 7, 2013 5:45:58 AM UTC-6, Martin Thompson wrote:
    I'd be surprised, I believe all that happens is an implicit resolved signal is formed for the connection of an unresolved signal to a resolved one.

    No, an implicit signal in between the two would force an additional delta-delay.

    In VHDL 2008, it's no different for SULV/SLV than std_ulogic/std_logic assignments and associations have been since '87.

    Andy
    Andy, Mar 8, 2013
    #6
  7. Andy <> writes:

    > On Thursday, March 7, 2013 5:45:58 AM UTC-6, Martin Thompson wrote:
    > I'd be surprised, I believe all that happens is an implicit resolved signal is formed for the connection of an unresolved signal to a resolved one.
    >
    > No, an implicit signal in between the two would force an additional delta-delay.


    Indeed so, not sure what I was thinking!

    >
    > In VHDL 2008, it's no different for SULV/SLV than std_ulogic/std_logic assignments and associations have been since '87.
    >


    Agreed

    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.co.uk/capabilities/39-electronic-hardware
    Martin Thompson, Mar 11, 2013
    #7
  8. KJ <> writes:

    > On Thursday, March 7, 2013 6:45:58 AM UTC-5, Martin Thompson wrote:
    >> Then, (IIRC) the only time it's a pain is (pre 2008) when you have to use an
    >> IP core which uses resolved vectors. Then an intermediate signal is required.

    >
    > Minor point...You can put the conversion right in the port map without having to create any intermediate signals.
    >
    > DUT : ip_core_with_slv port map(
    > std_logic_vector(a) => my_sulv_a,
    > b => std_ulogic_vector(my_sulv_b));
    >


    Can you? Pre-2008? I was under the impression you couldn't, but it's
    been a long time since I've had to try, and I don't feel up to grappling
    with the LRM this morning!

    Cheers,
    Martin

    --

    TRW Conekt - Consultancy in Engineering, Knowledge and Technology
    http://www.conekt.co.uk/capabilities/39-electronic-hardware
    Martin Thompson, Mar 11, 2013
    #8
  9. gsteemso

    Andy Guest

    Re: Resolved vs. Unresolved standard logic, and when to get away withusing each

    Re: conversion functions on ports

    Before or after -2008, a conversion function that returns an unconstrained array type/subtype cannot be used on an unconstrained port (the component/entity cannot determine what size its port is). Also the conversion functioncan take only one argument, so you cannot use "to_unsigned(int, size)".

    Note that non-built-in conversion functions impart a delta-cycle delay fromthe actual to the port (and/or vise versa when the conversion function is called on the formal).

    Built-in conversion functions (not really functions) are defined for conversion between "closely related" types (e.g. arrays of elements of the same base type). Example:

    -- output conversion => input conversion
    unsigned(my_constrained_slv_bidi_port) => std_logic_vector(my_unsigned)


    Andy
    Andy, Mar 18, 2013
    #9
    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. jozo
    Replies:
    1
    Views:
    2,221
    Ralf Hildebrandt
    May 16, 2004
  2. Yoon-Soo Lee
    Replies:
    5
    Views:
    4,214
    Chris \( Val \)
    Jan 2, 2004
  3. Vincent Ly
    Replies:
    14
    Views:
    14,662
    Arne Vajhøj
    Dec 3, 2009
  4. spike
    Replies:
    8
    Views:
    1,463
    Steve Holden
    Feb 9, 2010
  5. Pat Maddox
    Replies:
    6
    Views:
    152
    Marcin Mielżyński
    Jan 20, 2006
Loading...

Share This Page