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, Mar 7, 2013
    1. Advertisements

  2. gsteemso

    Robert Miles Guest

    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
    1. Advertisements

  3. Really? I keep referring back to it to *find* the details I haven't used for a while!
    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'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.

    Martin Thompson, Mar 7, 2013
  4. gsteemso

    KJ Guest

    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
  5. gsteemso

    valtih1978 Guest

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

    Andy Guest

    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, Mar 8, 2013
  7. Indeed so, not sure what I was thinking!

    Martin Thompson, Mar 11, 2013
  8. 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!

    Martin Thompson, Mar 11, 2013
  9. gsteemso

    Andy Guest

    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, Mar 18, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.