BIT, STD_LOGIC,STD_ULOGIC

Discussion in 'VHDL' started by RealInfo, Jan 8, 2009.

  1. RealInfo

    RealInfo Guest

    Hi all

    There is some dilema that allways confuses me.

    When I define signals and ports , which declaration is to be used ?
    BIT , STD_LOGIC or STD_ULOGIC ???

    What is the exact criterion to follow in the first stages of design and
    declarations ?

    Thanks in advance
    EC
     
    RealInfo, Jan 8, 2009
    #1
    1. Advertising

  2. RealInfo

    Guest

    std_logic
     
    , Jan 8, 2009
    #2
    1. Advertising

  3. RealInfo

    Andy Peters Guest

    On Jan 8, 10:25 am, "RealInfo" <> wrote:
    > Hi all
    >
    > There is some dilema that allways confuses me.
    >
    > When I define signals and ports , which declaration is to be used ?
    > BIT , STD_LOGIC or STD_ULOGIC ???
    >
    > What is the exact criterion to follow in the first stages of design and
    > declarations ?


    Use std_logic and std_logic_vector.

    The bit type knows only about '1' and '0'. std_logic adds more useful
    modeling constructs such as 'Z' (high-impedance), 'X' (conflicted or
    unknown), 'U' (undriven), etc. std_ulogic is "unresolved," meaning
    that you have to provide a resolution function to handle things like
    tristate logic.

    For entities that are internal to a design (meaning not brought to I/O
    pins), then you can use numeric_std's unsigned and signed types, too.
    Actually, you can use integer types, too, if you constrain the sizes.

    The reason you probably shouldn't use unsigned or signed types at I/O
    pins is because the tools might have issues with it. Specifically,
    most FPGA tools create a post-P&R timing model and those ports are
    always std_logic, so you can't use a test bench that expects the ports
    to be something else.

    -a
     
    Andy Peters, Jan 8, 2009
    #3
  4. RealInfo

    KJ Guest

    On Jan 8, 12:25 pm, "RealInfo" <> wrote:
    > Hi all
    >
    > There is some dilema that allways confuses me.
    >
    > When I define signals and ports , which declaration is to be used ?
    > BIT , STD_LOGIC or STD_ULOGIC ???
    >
    > What is the exact criterion to follow in the first stages of design and
    > declarations ?
    >


    For the top level entity in a design (assuming FPGA or CPLD, etc.),
    use std_logic. This can facilitate
    - Using the model within a CAD system produced VHDL netlist of a PCBA
    - Switching a testbench model to the post-route netlist version if you
    choose to run simulations with the post-route code.

    For all other entities and all internal signals
    - Use std_ulogic if the signal can only have one driver.
    - Use std_logic if the signal can legitimately have more than one
    driver.

    If you choose to use std_logic all the time (many do) you will have to
    find cases where you inadvertently connected multiple outputs
    together. In order to find these cases you can
    - (quick way) Synthesize the design, multiple outputs will cause an
    error.
    - (slow way) Simulate and debug.

    If you use std_ulogic where appropriate, then simply compiling the
    file with a simulator will immediately flag the error (faster than
    running a synthesis tool).

    Don't bother using type bit, it's lack of an unknown (i.e.
    std_ulogic's 'U', 'X', 'W') can lead one to believe that the design is
    'working' when in fact it will not.

    KJ
     
    KJ, Jan 8, 2009
    #4
  5. RealInfo

    Dave Guest

    On Jan 8, 12:25 pm, "RealInfo" <> wrote:
    > Hi all
    >
    > There is some dilema that allways confuses me.
    >
    > When I define signals and ports , which declaration is to be used ?
    > BIT , STD_LOGIC or STD_ULOGIC ???
    >
    > What is the exact criterion to follow in the first stages of design and
    > declarations ?
    >
    > Thanks in advance
    > EC


    Almost everyone uses std_logic and std_ulogic instead of the bit type,
    because they are so much more flexible. They allow not only the values
    of '1' and '0', but also a host of other values to represent other
    states such as a high-impedance state ('Z'), a weak pull-up ('W'),
    pull-ups and pull-downs ('H' and 'L'), unknown ('X'), don't care
    ('-'), and undefined ('U'). So I would definitely say not to use bit.

    Most of the time, std_logic is all you need. It is a resolved type,
    meaning that if you have multiple drivers of the same net, there is a
    function which defines what the overall value of the signal will be.
    For instance, if I have a std_logic signal some_sig, and I drive it
    with a 'L' pull-down in one process, but drive it with a '1' in
    another process, the signal will have the value '1', since the
    resolution function dictates that driving a signal overrides the pull-
    down, which is exactly the behavior that would happen in real life.
    The resolution function provides the complete set of rules for any
    combination of drivers.

    Sometimes, you may want to guarantee that a signal does not have
    multiple drivers on it, and in that case, you might choose to use
    std_ulogic. This type is exactly like std_logic in that is has 9
    values, but no resolution function, so if there are multiple drivers,
    an error will result in both simulation and synthesis.

    When you're doing math, it is often most convenient to use the signed
    and unsigned types from the ieee.numeric_std library. These are base
    on std_logic, and are resolved the same way that std_logic is, but
    have the added benefit that mathematical operators are defined for
    them. Do not ever use the std_logic_arith, std_logic_signed, or
    std_logic_unsigned libraries.

    Hope this helps.

    Dave
     
    Dave, Jan 8, 2009
    #5
  6. On 2009-01-08, <> wrote:

    |-----------|
    |"std_logic"|
    |-----------|

    I disagree. Use std_ulogic instead.
     
    Nicholas Collin Paul Gloucester, Jan 8, 2009
    #6
  7. RealInfo

    RealInfo Guest

    Many thanks for all those who took time and effor to answer my question .

    Be well
    EC


    "Dave" <> ???
    ??????:...
    On Jan 8, 12:25 pm, "RealInfo" <> wrote:
    > Hi all
    >
    > There is some dilema that allways confuses me.
    >
    > When I define signals and ports , which declaration is to be used ?
    > BIT , STD_LOGIC or STD_ULOGIC ???
    >
    > What is the exact criterion to follow in the first stages of design and
    > declarations ?
    >
    > Thanks in advance
    > EC


    Almost everyone uses std_logic and std_ulogic instead of the bit type,
    because they are so much more flexible. They allow not only the values
    of '1' and '0', but also a host of other values to represent other
    states such as a high-impedance state ('Z'), a weak pull-up ('W'),
    pull-ups and pull-downs ('H' and 'L'), unknown ('X'), don't care
    ('-'), and undefined ('U'). So I would definitely say not to use bit.

    Most of the time, std_logic is all you need. It is a resolved type,
    meaning that if you have multiple drivers of the same net, there is a
    function which defines what the overall value of the signal will be.
    For instance, if I have a std_logic signal some_sig, and I drive it
    with a 'L' pull-down in one process, but drive it with a '1' in
    another process, the signal will have the value '1', since the
    resolution function dictates that driving a signal overrides the pull-
    down, which is exactly the behavior that would happen in real life.
    The resolution function provides the complete set of rules for any
    combination of drivers.

    Sometimes, you may want to guarantee that a signal does not have
    multiple drivers on it, and in that case, you might choose to use
    std_ulogic. This type is exactly like std_logic in that is has 9
    values, but no resolution function, so if there are multiple drivers,
    an error will result in both simulation and synthesis.

    When you're doing math, it is often most convenient to use the signed
    and unsigned types from the ieee.numeric_std library. These are base
    on std_logic, and are resolved the same way that std_logic is, but
    have the added benefit that mathematical operators are defined for
    them. Do not ever use the std_logic_arith, std_logic_signed, or
    std_logic_unsigned libraries.

    Hope this helps.

    Dave
     
    RealInfo, Jan 8, 2009
    #7
  8. RealInfo

    Guest

    On Jan 8, 2:54 pm, Nicholas Collin Paul Gloucester
    <Colin_Paul@Bluewhite64_for_Gloster.GIAN.fis.priv> wrote:
    > On 2009-01-08, <> wrote:
    >
    > |-----------|
    > |"std_logic"|
    > |-----------|
    >
    > I disagree. Use std_ulogic instead.


    Sure, but...

    The use of std_ulogic (as opposed to std_logic) has the characteristic
    that all tri-state buffers will need to be instantiated explicitly in
    the design. The automatic inference of tristate buffers for external
    bus interface logic is, IMHO, a very elegant and concise capability of
    the language and of (most) tools, and is reasonably well supported by
    the major synthesis players. Mandating std_ulogic is right up there
    with mandating SPICE netlists as your root design base. (Well, OK, I'm
    exaggerating a little, but I hope you get my drift).

    I once did a spec in which I required all our top-level FPGA designers
    (let's say tens of them) to manually instantiate tri-state buffers on
    a bus interface, in order to preserve exactly the clarity and
    exactness of purpose to which I suspect you're alluding. Can you
    guess how many of them got it right on the first, second, or third
    tries, and how many bloody emails I had to respond to, about something
    as trivial as a tri-state buffer? Finding the right balance of
    pragmatism and aesthetic design purity isn't always easy :-(

    - Kenn
     
    , Jan 9, 2009
    #8
  9. On 9 Jan., 05:11, wrote:
    > On Jan 8, 2:54 pm, Nicholas Collin Paul Gloucester
    >
    > <Colin_Paul@Bluewhite64_for_Gloster.GIAN.fis.priv> wrote:
    > > On 2009-01-08, <> wrote:

    >
    > > |-----------|
    > > |"std_logic"|
    > > |-----------|

    >
    > > I disagree. Use std_ulogic instead.

    >
    > Sure, but...
    >
    > The use of std_ulogic (as opposed to std_logic) has the characteristic
    > that all tri-state buffers will need to be instantiated explicitly in
    > the design. The automatic inference of tristate buffers for external
    > bus interface logic is, IMHO, a very elegant and concise capability of


    Especially if you like to see internal tristate in places the designer
    didn't intend to :=).

    I prefer to have the tristates on a higher level of design hierarchy
    and not (as often seen) on the ff descirption. This is important for
    code reusability, to allow including of existing code without
    inspecting each ff description.

    bye Thomas
     
    Thomas Stanka, Jan 9, 2009
    #9
  10. wrote:


    >I once did a spec in which I required all our top-level FPGA designers
    >(let's say tens of them) to manually instantiate tri-state buffers on
    >a bus interface, in order to preserve exactly the clarity and
    >exactness of purpose to which I suspect you're alluding. Can you
    >guess how many of them got it right on the first, second, or third
    >tries, and how many bloody emails I had to respond to, about something
    >as trivial as a tri-state buffer? Finding the right balance of
    >pragmatism and aesthetic design purity isn't always easy :-(


    Sorry, but I have to ask too. What do you mean by manually instantiating
    a tristate?

    I just put a bunch of lines like the following in the top-level module,
    one line for each tristate output, which seems to me to be compact and
    unambiguous:

    FOO <= FOO_RD when (OE = '1') else 'Z';

    --
    Dave Farrance
     
    Dave Farrance, Jan 9, 2009
    #10
  11. RealInfo

    Guest

    On Jan 9, 4:50 am, Dave Farrance
    <> wrote:
    > wrote:
    > >I once did a spec in which I required all our top-level FPGA designers
    > >(let's say tens of them) to manually instantiate tri-state buffers on
    > >a bus interface, in order to preserve exactly the clarity and
    > >exactness of purpose to which I suspect you're alluding.  Can you
    > >guess how many of them got it right on the first, second, or third
    > >tries, and how many bloody emails I had to respond to, about something
    > >as trivial as a tri-state buffer? Finding the right balance of
    > >pragmatism and aesthetic design purity isn't always easy :-(

    >
    > Sorry, but I have to ask too. What do you mean by manually instantiating
    > a tristate?
    >
    > I just put a bunch of lines like the following in the top-level module,
    > one line for each tristate output, which seems to me to be compact and
    > unambiguous:
    >
    > FOO <= FOO_RD when (OE = '1') else 'Z';
    >
    > --
    > Dave Farrance


    Yes, it's reasonably compact and unambiguous. But someone always
    thinks it was supposed to be active high versus active low, or forgets
    to put that key line in when building the final chip and kills the
    whole CPU bus, or in the heat of the moment accidentally writes an
    open collector output by mis-typing the one-line template, or uses the
    wrong OE, or something along those lines. It's amazing how many ways
    there can be to mis-interpret one line of code. Not because the guys
    doing it are dumb, it's just Murphy's law.

    - Kenn
     
    , Jan 9, 2009
    #11
  12. RealInfo

    KJ Guest

    <> wrote in message
    news:...
    On Jan 9, 4:50 am, Dave Farrance
    <> wrote:
    > > I just put a bunch of lines like the following in the top-level module,
    > > one line for each tristate output, which seems to me to be compact and
    > > unambiguous:
    > >
    > > FOO <= FOO_RD when (OE = '1') else 'Z';
    > >
    > > --
    > > Dave Farrance

    >
    > Yes, it's reasonably compact and unambiguous. But someone always
    > thinks it was supposed to be active high versus active low, or forgets
    > to put that key line in when building the final chip and kills the
    > whole CPU bus, or in the heat of the moment accidentally writes an
    > open collector output by mis-typing the one-line template, or uses the
    > wrong OE, or something along those lines. It's amazing how many ways
    > there can be to mis-interpret one line of code. Not because the guys
    > doing it are dumb, it's just Murphy's law.


    That's why you use a simulator and why you should model the actual PCBA and
    use as one of your testbenches.

    Kevin Jennings
     
    KJ, Jan 9, 2009
    #12
  13. On 2009-01-09, <>
    wrote:

    |----------------------------------------------------------------------|
    |"[..] |
    | |
    |[..], in order to preserve exactly the clarity and |
    |exactness of purpose to which I suspect you're alluding." |
    |----------------------------------------------------------------------|

    You gave me more credit than I deserve.

    |----------------------------------------------------------------------|
    |"[..] Finding the right balance of |
    |pragmatism and aesthetic design purity isn't always easy :-( " |
    |----------------------------------------------------------------------|

    Truly. There can be no completely satisfactory balance.
     
    Nicholas Collin Paul Gloucester, Jan 9, 2009
    #13
  14. RealInfo

    Dave Guest

    On Jan 8, 3:17 pm, "RealInfo" <> wrote:
    > Many thanks for all those who took time and effor to answer my question .
    >
    > Be well
    > EC
    >


    You may also want to keep in mind that, when using std_logic and
    std_ulogic, in the following code

    if some_sig = '0' then
    sig2 <= '1';
    else
    sig2 <= '0';
    end if;

    sig will get '0' in simulation, even if some_sig's value is 'X', 'U',
    'L', or anything other than '0'. There is a function which is
    sometimes useful called to_X01, which will map the nine possible
    values into three like so:

    '1', 'H' => '1'
    '0', 'L' => '0'
    'X', 'U', '-', 'W', 'Z' => 'X'

    Similarly, there is a to_X01Z function which also preserves the 'Z'
    value if you'd like. They work on std_logic, std_ulogic,
    std_logic_vector, and std_ulogic_vector.

    Also, does anyone here know if there are any plans in the VHDL
    language to allow the '-' to represent a don't-care value in
    conditional and case statements for synthesis? I thought I had heard
    somewhere that this idea was possibly going to be in the next
    iteration.

    Dave
     
    Dave, Jan 9, 2009
    #14
  15. RealInfo

    HT-Lab Guest

    "Dave" <> wrote in message
    news:...
    On Jan 8, 3:17 pm, "RealInfo" <> wrote:
    > Many thanks for all those who took time and effor to answer my question .
    >
    > Be well
    > EC
    >
    >

    ..>.
    >Also, does anyone here know if there are any plans in the VHDL
    >language to allow the '-' to represent a don't-care value in
    >conditional and case statements for synthesis? I thought I had heard
    >somewhere that this idea was possibly going to be in the next
    >iteration.
    >
    >Dave
    >


    Yes, from Jim Lewis' presentation (www.synthworks.com) VHDL2008 will support
    his, example:

    -- Priority Encoder
    process (Request)
    begin
    case? Request is
    when "1---" => Grant <= "1000" ;
    when "01--" => Grant <= "0100" ;
    when "001-" => Grant <= "0010" ;
    when "0001" => Grant <= "0001" ;
    when others => Grant <= "0000" ;
    end case ;
    end process ;

    So far only Aldec supports part of this new standard,

    Hans.
    www.ht-lab.com
     
    HT-Lab, Jan 9, 2009
    #15
  16. RealInfo

    Guest

    On Jan 9, 7:31 am, "KJ" <> wrote:
    > <> wrote in message
    >
    > news:...
    > > Yes, it's reasonably compact and unambiguous. But someone always
    > > thinks it was supposed to be active high versus active low, or forgets
    > > to put that key line in when building the final chip and kills the
    > > whole CPU bus, or in the heat of the moment accidentally writes an
    > > open collector output by mis-typing the one-line template, or uses the
    > > wrong OE, or something along those lines. It's amazing how many ways
    > > there can be to mis-interpret one line of code. Not because the guys
    > > doing it are dumb, it's just Murphy's law.

    >
    > That's why you use a simulator and why you should model the actual PCBA and
    > use as one of your testbenches.
    >
    > Kevin Jennings


    Can't argue with that! It's interesting that, for every subtle,
    nuanced, and intricate bug that trips you up, there's also a stupid,
    simple bug that more attention to "the basics" and good design
    practices should have caught. You can spend man-months designing an
    insanely complicated design, simulate the heck out of it, then get
    tripped up because the DRAM clock on the PCB got the + and - phases
    the wrong way 'round.

    - Kenn
     
    , Jan 9, 2009
    #16
  17. RealInfo

    Guest

    On 8 ינו×ר, 19:25, "RealInfo" <> wrote:
    > Hi all
    >
    > There is some dilema that allways confuses me.
    >
    > When I define signals and ports , which declaration is to be used ?
    > BIT , STD_LOGIC or STD_ULOGIC ???
    >
    > What is the exact criterion to follow in the first stages of design and
    > declarations ?
    >
    > Thanks in advance
    > EC


    I rarely see people use bit. I assume if your design is large, memory
    consumption (by the simulator) is an issue. std logic takes more
    memory, as it has more states than 0 and 1 (U, Z, X, L, H).
    You may want to use bit where there is a single driver to a net.

    Some VHDL and VERILOG free examples at:http://bknpk.no-ip.biz/
    index.html
     
    , Jan 10, 2009
    #17
    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. Mohammed  A.khader

    std_logic vs bit

    Mohammed A.khader, Sep 10, 2004, in forum: VHDL
    Replies:
    11
    Views:
    13,547
    Jim Lewis
    Sep 17, 2004
  2. Replies:
    5
    Views:
    18,833
    vipinlal
    Mar 9, 2010
  3. Amal
    Replies:
    2
    Views:
    844
  4. Diego UTN-FRP
    Replies:
    4
    Views:
    4,628
    Diego UTN-FRP
    Nov 29, 2009
  5. whygee
    Replies:
    9
    Views:
    994
    whygee
    Apr 17, 2010
Loading...

Share This Page