records in port declarations

Discussion in 'VHDL' started by Christian Schleiffer, Aug 9, 2006.

  1. Hi,

    I have a design with quite a lot of Xilinx FPGAs on the same bus and I
    would like to use records to make the port declarations smaller and
    easier to read. The bus consists of some bidirectional and some
    unidirectional signals. Now I'm wondering what the synthesis tools (XST
    or Synplify) will do if I declare the whole record as inout. Will they
    infer tristate buffers all over the designs, even though I'm only
    writing or reading to the unidirectional signals?
    Is it wise at all to group the different signal types in one record?
    Thanks for any comments on this.

    Best regards
    Chris


    --
    Christian Schleiffer
    Communication Security (COSY)
    Dept. of Electr. Eng. & Information Science
    Ruhr-University Bochum, Germany
    http://www.crypto.rub.de
    Christian Schleiffer, Aug 9, 2006
    #1
    1. Advertising

  2. Christian Schleiffer

    Ben Jones Guest

    "Christian Schleiffer" <> wrote in message
    news:...
    > Hi,
    >
    > I have a design with quite a lot of Xilinx FPGAs on the same bus and I
    > would like to use records to make the port declarations smaller and
    > easier to read. The bus consists of some bidirectional and some
    > unidirectional signals. Now I'm wondering what the synthesis tools (XST
    > or Synplify) will do if I declare the whole record as inout. Will they
    > infer tristate buffers all over the designs, even though I'm only
    > writing or reading to the unidirectional signals?


    Last time I tried this, that's exactly what happened. Avoid inout like the
    plague unless you really do mean a tri-state buffer.

    > Is it wise at all to group the different signal types in one record?


    Yes - it certainly makes for less typing, and it allows you to easily modify
    the set of signal that make up a particular interface without having to
    change a million files.

    Your best bet is to gang up all the input signals, all the output signals,
    and all the bidirectional signals into their own record groups. It's not
    ideal, but it's better than nothing - and it does work in XST and Synplify.
    For smaller buses with few signals, this is usually overkill though.

    Good luck!

    -Ben-
    Ben Jones, Aug 9, 2006
    #2
    1. Advertising

  3. Christian Schleiffer

    KJ Guest

    "Christian Schleiffer" <> wrote in message
    news:...
    > Hi,
    >
    > I have a design with quite a lot of Xilinx FPGAs on the same bus and I
    > would like to use records to make the port declarations smaller and
    > easier to read. The bus consists of some bidirectional and some
    > unidirectional signals. Now I'm wondering what the synthesis tools (XST
    > or Synplify) will do if I declare the whole record as inout.


    They will be quite happy to oblige (at least Synplify will, I haven't tried
    of late with XST).

    > Will they
    > infer tristate buffers all over the designs, even though I'm only
    > writing or reading to the unidirectional signals?


    And then they'll selectlively 'optomize' out the tri-state controls when
    they see that the inputs are never being driven and that the outputs (not
    inouts) are always being driven leaving tri-state controls only on the
    inouts. All the record type is doing from a synthesis perspective is giving
    a different name to signals. Since the name itself is irrelevant to the
    synthesis operation, the tools generally don't care.

    > Is it wise at all to group the different signal types in one record?


    As Ben pointed out it would be wiser to see if you can group the inputs into
    one record, the outputs into another, the inouts into a third. Some reasons
    for doing this would be

    - Code clarity, declaring an input as an inout leads to headaches for those
    picking up the code later on. If I picked up some code and saw use of
    inouts everywhere it would probably give me the impression of a bit of
    laziness on the part of the original designer unless it was just immediately
    obvious why such a grouping was a good thing (and in certain cases, I think
    it can be 'good'). In 'most' cases, one guys output is the other guys input
    so grouping by mode into a record doesn't cause any readability issues with
    the other FPGA designs in the overall board design. If that's not the case
    though then using inouts throughout may be appropriate.

    - Extra code that would not be needed were it not for grouping everything as
    inouts (i.e. All elements of the record that are really only inputs would
    also need to have the line of code that sets them to 'Z'). The cleanest way
    to handle this would be to define a constant of the record type that is
    being used where you set all elements to 'Z' regardless of the intended mode
    (i.e. in, out, inout) and then have a line of code that sets the entire
    signal to this constant. That way in one fell swoop all inputs will have a
    'Z' driving them. The outs and inouts will have the 'Z' driving as well but
    then will also have whatever real equations as well so they will be
    overridden. Also, if you have to add or subtract elements to the record or
    change the intended mode (less likely one would think) you won't have to
    worry about forgetting one of these default assignment as long as it
    compiles since adding/removing a record element without also updating the
    magic constant that has all 'Z' will result in an immediate easy to fix
    error when you compile it.

    KJ
    KJ, Aug 9, 2006
    #3
  4. Ben Jones wrote:
    > Last time I tried this, that's exactly what happened. Avoid inout like the
    > plague unless you really do mean a tri-state buffer.


    I was hoping that the optimization process will eliminate the buffers again.

    >> Is it wise at all to group the different signal types in one record?

    >
    > Yes - it certainly makes for less typing, and it allows you to easily modify
    > the set of signal that make up a particular interface without having to
    > change a million files.


    That's what I was thinking of, since the hardware is custom made. The
    bus signals might change later, you'll never know...

    > Your best bet is to gang up all the input signals, all the output signals,
    > and all the bidirectional signals into their own record groups.


    Yes, I already thought about that. But still, having only one record for
    the bus would look much nicer in the source ;-)

    Bye
    Chris

    --
    Christian Schleiffer
    Communication Security (COSY)
    Dept. of Electr. Eng. & Information Science
    Ruhr-University Bochum, Germany
    http://www.crypto.rub.de
    Christian Schleiffer, Aug 9, 2006
    #4
  5. KJ wrote:

    >> Will they
    >> infer tristate buffers all over the designs, even though I'm only
    >> writing or reading to the unidirectional signals?

    >
    > And then they'll selectlively 'optomize' out the tri-state controls when
    > they see that the inputs are never being driven and that the outputs (not
    > inouts) are always being driven leaving tri-state controls only on the
    > inouts.


    Ok, that's what I hoped.

    >> Is it wise at all to group the different signal types in one record?

    >
    > As Ben pointed out it would be wiser to see if you can group the inputs into
    > one record, the outputs into another, the inouts into a third.


    Seems, like this is where I'm heading.

    Thanks a lot, cheers
    Chris

    --
    Christian Schleiffer
    Communication Security (COSY)
    Dept. of Electr. Eng. & Information Science
    Ruhr-University Bochum, Germany
    http://www.crypto.rub.de
    Christian Schleiffer, Aug 9, 2006
    #5
  6. On Wed, 09 Aug 2006 13:13:53 +0200, Christian Schleiffer
    <> wrote:

    > having only one record for
    >the bus would look much nicer in the source ;-)


    Have you looked at the interface construct in SystemVerilog?
    It aims to deal with exactly this issue. Personally I think the
    jury's still out on whether it's entirely successful, but it's
    a very interesting approach. Sadly, synthesis support is
    still somewhat limited, although Synopsys DC does a good
    job with interfaces and I think Mentor Precision supports
    them now. Don't know about Synplify, sorry.
    --
    Jonathan Bromley, Consultant

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

    Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
    Jonathan Bromley, Aug 9, 2006
    #6
  7. Christian Schleiffer

    Amal Guest

    Jonathan Bromley wrote:
    > On Wed, 09 Aug 2006 13:13:53 +0200, Christian Schleiffer
    > <> wrote:
    >
    > Have you looked at the interface construct in SystemVerilog?
    > It aims to deal with exactly this issue.


    You don't need SystemVerilog :p, you just need to be paitient till
    VHDL-200x comes out ;). Check out:
    http://www.vhdl.org/vhdl-200x/vhdl-200x-ft/proposals/ft17_composite_interface_mode.txt

    This is similar to SystemVerilog interfaces.

    -- Amal
    Amal, Aug 9, 2006
    #7
    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. John T. Goodman

    Overhead of 4-port over 2-port SRAM

    John T. Goodman, Jan 25, 2005, in forum: VHDL
    Replies:
    0
    Views:
    586
    John T. Goodman
    Jan 25, 2005
  2. Sean Wolfe
    Replies:
    1
    Views:
    2,234
    Joerg Jooss
    Apr 28, 2005
  3. Luke Airig
    Replies:
    0
    Views:
    771
    Luke Airig
    Dec 31, 2003
  4. Dan

    Delete records or update records

    Dan, May 10, 2004, in forum: ASP General
    Replies:
    1
    Views:
    451
    Ray at
    May 10, 2004
  5. Replies:
    3
    Views:
    640
    Anthony Jones
    Nov 2, 2006
Loading...

Share This Page