Good practice for signal types

Discussion in 'VHDL' started by Alex Young, Oct 11, 2004.

  1. Alex Young

    Alex Young Guest

    Hi all,

    Having only recently started using vhdl I am wondering if there are any
    recomendations for how to use types within designs?
    It seems that the most generic type is std_logic(_vector). Is it generally a
    good idea to use this type to pass data around between modules/entities?
    ( Argh what is the correct name for these? I am used to Verilog!)

    In particular how would you handle the design of something like an ALU. It
    would seem to make sense to give it signed/unsigned types. Should I pass
    std_logic values and then type convert to signed within the architecture of
    the ALU?

    A similar question relating to boolean values. It seems that using booleans
    will give cleaner code. i.e.
    zero_flag := alu_out = 0;
    as opposed to
    if alu_out = 0 then
    zero_flag := '1';
    else
    zero_flag := '0';
    end if;
    I guess that this will have problems with uninitialised values though. Again
    what would be considered best practice?

    Thanks for your help,

    --
    Alex Young
     
    Alex Young, Oct 11, 2004
    #1
    1. Advertising

  2. Alex Young wrote:

    > Having only recently started using vhdl I am wondering if there are any
    > recomendations for how to use types within designs?
    > It seems that the most generic type is std_logic(_vector). Is it generally a
    > good idea to use this type to pass data around between modules/entities?


    Yes, but often it is quite better to use the unresolved
    std_Ulogic(_vector). Why?
    * Often synthesis tools are configured to change every I/O signal in an
    entity to std_ulogic_(vector).
    * As this signal is unresolved, multiple drivers are not allowed.
    Therefore if one drives to a signal from more than one process (as a
    mistake), one will get an error and the bug search is quick.
    If you really need multiple drivers (tri-state busses), then use
    std_logic(_vector). As this is seldom, it helps you to take care for
    these special cases.


    > In particular how would you handle the design of something like an ALU. It
    > would seem to make sense to give it signed/unsigned types. Should I pass
    > std_logic values and then type convert to signed within the architecture of
    > the ALU?


    Yes. At the very point of conversion it looks ugly, but these
    conversions are "seldom" needed. An example for the ALU:

    use IEEE.Numeric_std.all;

    signal sum,a,b : std_ulogic_vector(15 downto 0);

    sum<=std_ulogic_vector(unsigned(a) + unsigned(b));


    Ralf
     
    Ralf Hildebrandt, Oct 11, 2004
    #2
    1. Advertising

  3. Alex Young wrote:

    > Having only recently started using vhdl I am wondering if there are any
    > recomendations for how to use types within designs?
    > It seems that the most generic type is std_logic(_vector). Is it generally a
    > good idea to use this type to pass data around between modules/entities?


    I use std_logic_vector for my top entity ports for compatibility
    with other designers and other tools. For top bit ports, I use
    std_ulogic for IN or OUT and std_logic for INOUT tristates.
    For internal instance ports and process variables I often use
    unsigned, signed, std_ulogic and boolean.

    > ( Argh what is the correct name for these? I am used to Verilog!)


    I have heard both module and entity meaning entity/architecture pair.
    I say "entity" for VHDL audiences or "module" otherwise.

    > In particular how would you handle the design of something like an ALU. It
    > would seem to make sense to give it signed/unsigned types. Should I pass
    > std_logic values and then type convert to signed within the architecture of
    > the ALU?


    Sure: alu_v := signed(alu_port);

    > A similar question relating to boolean values. It seems that using booleans
    > will give cleaner code. i.e.
    > zero_flag := alu_out = 0;
    > as opposed to
    > if alu_out = 0 then
    > zero_flag := '1';
    > else
    > zero_flag := '0';
    > end if;
    > I guess that this will have problems with uninitialised values though. Again
    > what would be considered best practice?


    That's a trade-off discussed here recently:

    http://groups.google.com/groups?q=vhdl boolean synthesis me.net

    If you are careful with initialization booleans are fine.
    You can also write your own conversion functions to std_ulogic:

    zero_flag := active_high(alu_out = 0);



    -- Mike Treseler
     
    Mike Treseler, Oct 11, 2004
    #3
  4. Alex Young

    Alan Fitch Guest

    "Mike Treseler" <> wrote in message
    news:...
    > Alex Young wrote:
    >
    > > Having only recently started using vhdl I am wondering if there

    are any
    > > recomendations for how to use types within designs?
    > > It seems that the most generic type is std_logic(_vector). Is it

    generally a
    > > good idea to use this type to pass data around between

    modules/entities?
    >
    > I use std_logic_vector for my top entity ports for compatibility
    > with other designers and other tools. For top bit ports, I use
    > std_ulogic for IN or OUT and std_logic for INOUT tristates.
    > For internal instance ports and process variables I often use
    > unsigned, signed, std_ulogic and boolean.
    >
    > > ( Argh what is the correct name for these? I am used to Verilog!)

    >
    > I have heard both module and entity meaning entity/architecture

    pair.
    > I say "entity" for VHDL audiences or "module" otherwise.
    >
    > > In particular how would you handle the design of something like an

    ALU. It
    > > would seem to make sense to give it signed/unsigned types. Should

    I pass
    > > std_logic values and then type convert to signed within the

    architecture of
    > > the ALU?

    >
    > Sure: alu_v := signed(alu_port);
    >
    > > A similar question relating to boolean values. It seems that using

    booleans
    > > will give cleaner code. i.e.
    > > zero_flag := alu_out = 0;
    > > as opposed to
    > > if alu_out = 0 then
    > > zero_flag := '1';
    > > else
    > > zero_flag := '0';
    > > end if;
    > > I guess that this will have problems with uninitialised values

    though. Again
    > > what would be considered best practice?

    >
    > That's a trade-off discussed here recently:
    >
    > http://groups.google.com/groups?q=vhdl boolean synthesis me.net
    >
    > If you are careful with initialization booleans are fine.
    > You can also write your own conversion functions to std_ulogic:
    >
    > zero_flag := active_high(alu_out = 0);
    >


    Another couple of points - if you are doing arithmetic you can
    use either integer or vector types. Integers simulate faster, but
    are restricted to 32 bits for synthesis (even if some simulators
    support
    64 bits!), are harder to use for bit manipulation, and don't represent
    initial states correctly.

    If you find yourself doing lots of type conversions, that probably
    means
    you are using the "wrong" types. A good plan is to use
    std_logic_vector
    / std_logic ports (or std_u... as discussed above), and then convert
    to
    appropriate types within the architecture, for instance using
    variables
    or signals of type unsigned/signed (from Numeric_std). You then just
    need to convert the result back to the correct type to drive the
    output
    port. If you design an alu, and you end up writing

    F <= std_logic_vector (unsigned(a) + unsigned(b));
    ...
    F <= std_logic_vector( unsigned(a) sll 1 );

    and so on, it makes more sense to do

    process(a, b)

    variable va, vb : unsigned(7 downto 0); -- assuming a, b 8 bits
    variable result : unsigned(8 downto 0);
    begin
    va := resize(va, 9);
    vb := resize(vb, 9);

    case...
    result := a + b;
    result = a sll 1;

    ...
    f <= std_logic_vector(result);
    end case;

    end process;

    and all the arithmetic just "looks nice" :) at the cost of some
    initial and final type conversions.


    Regarding "entity", the VHDL equivalent for module is strictly "design
    entity".
    A design entity consists of the interface (entity) and the body
    (architecture)

    regards
    Alan





    --
    Alan Fitch
    Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project
    Services

    Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
    1AW, UK
    Tel: +44 (0)1425 471223 mail:

    Fax: +44 (0)1425 471573 Web:
    http://www.doulos.com

    The contents of this message may contain personal views which are not
    the
    views of Doulos Ltd., unless specifically stated.
     
    Alan Fitch, Oct 12, 2004
    #4
    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. Michael Pronath
    Replies:
    1
    Views:
    1,175
    Diez B. Roggisch
    Jan 3, 2005
  2. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    469
    Jack Orenstein
    Sep 18, 2005
  3. Weng Tianxiang
    Replies:
    2
    Views:
    661
    Jonathan Bromley
    Jan 30, 2007
  4. vlsidesign
    Replies:
    26
    Views:
    988
    Keith Thompson
    Jan 2, 2007
  5. SM
    Replies:
    9
    Views:
    507
Loading...

Share This Page