Daughter Cards, Headers, INOUT

Discussion in 'VHDL' started by Brad Smallridge, May 7, 2007.

  1. If you have a mother board that accepts various
    daughter boards, how do you define the header in
    such a way to accomodate different IO functions?
    Specifically should you define all the header pins
    on the mother board as INOUT and then have a daughter
    board module that defines the INs and OUTs of the
    daughter card? How does this effect the synthesis
    of the IO pins? Is, for example, an INOUT tristate
    pin with the output always disabled exactly
    equivalent to an IN pin?

    Brad Smallridge
    AiVision
     
    Brad Smallridge, May 7, 2007
    #1
    1. Advertising

  2. Brad Smallridge

    KJ Guest

    "Brad Smallridge" <> wrote in message
    news:...
    > If you have a mother board that accepts various
    > daughter boards, how do you define the header in
    > such a way to accomodate different IO functions?
    > Specifically should you define all the header pins
    > on the mother board as INOUT and then have a daughter
    > board module that defines the INs and OUTs of the
    > daughter card?

    Yes...either that or don't model the header at all. The mother board and
    daughter board will each have an entity definition which will define the I/O
    signals for the board (which would correspond to any headers/connectors that
    are on each board). Your system level model of these two will instantiate
    each of these two entities and then connect them however it is they are
    meant to be connected in a real system.

    Modelling the header in a simulation model kind of gums up the works a bit
    and doesn't end up adding any real particular value. Since the header is
    part of a board, it would end up being instantiated in the architecture for
    a board as well. Like any good connector/header, each pin by itself is
    bi-directional with no 'input' or 'output', so the entity for the
    header/connector model would have however many pins are on the header and
    they would all be 'inout' (example, io_pins: std_logic_vector(49 downto 0)
    for a 50 pin header). But the header is a passive device, the active driver
    for any signal on that header would be some other device on each board. So
    the header model would simply be to drive all I/O pins to 'Z'. But now,
    since the header model is in there, then all off the I/O for both boards has
    to be 'inout' simply because the header is connected to each and every
    signal and it (the header) defines them to be 'inout'. You could of course
    define a 'board specific header' model that mimic the signal direction of
    the real board....but then ask yourself why bother? That information is
    already contained in whatever part(s) are modelling the active circuitry
    that drives the I/O signals for each board.

    If you're using a CAD tool generated PCBA VHDL model for each of the boards,
    then the header will be instantiated and there isn't much you can do about
    it other than to model the header as an all 'Z' driver or create board
    specific header models. If you're simply cobbling together your own system
    model then adding the header to the model adds no real value and, as I
    explained above, takes more effort and makes it less clear about real signal
    directions.

    > How does this effect the synthesis
    > of the IO pins? Is, for example, an INOUT tristate
    > pin with the output always disabled exactly
    > equivalent to an IN pin?

    From a simulation perspective, no they are not equivalent, because an 'in'
    pin can not have any drivers on it and an 'inout' is a driver even if that
    driver is always disabled. It won't compile.

    KJ
     
    KJ, May 8, 2007
    #2
    1. Advertising

  3. > Yes...either that or don't model the header at all. The mother board and
    > daughter board will each have an entity definition which will define the
    > I/O signals for the board (which would correspond to any
    > headers/connectors that are on each board). Your system level model of
    > these two will instantiate each of these two entities and then connect
    > them however it is they are meant to be connected in a real system.


    Yeah KJ, this harps on something else I never really understood about VHDL.
    How does one simulate the entire board? If the top level is your FPGA design
    then how do you simulate, for example, the FPGA working with a memory chip?
    What do you mean by "your system level model"? Do you have a level above
    your FPGA design?

    > Modelling the header in a simulation model kind of gums up the works a bit
    > and doesn't end up adding any real particular value. Since the header is
    > part of a board, it would end up being instantiated in the architecture
    > for a board as well. Like any good connector/header, each pin by itself
    > is bi-directional with no 'input' or 'output', so the entity for the
    > header/connector model would have however many pins are on the header and
    > they would all be 'inout' (example, io_pins: std_logic_vector(49 downto 0)
    > for a 50 pin header). But the header is a passive device, the active
    > driver for any signal on that header would be some other device on each
    > board. So the header model would simply be to drive all I/O pins to 'Z'.
    > But now, since the header model is in there, then all off the I/O for both
    > boards has to be 'inout' simply because the header is connected to each
    > and every signal and it (the header) defines them to be 'inout'.


    Thats unfortunate. VHDL allows std_logic_vectors to be unconstrained in
    length.
    Why can't they be unconstrained in terms of IO?

    > You could of course define a 'board specific header' model that mimic the
    > signal direction of the real board....but then ask yourself why bother?
    > That information is already contained in whatever part(s) are modelling
    > the active circuitry that drives the I/O signals for each board.
    >
    > If you're using a CAD tool generated PCBA VHDL model for each of the
    > boards, then the header will be instantiated and there isn't much you can
    > do about it other than to model the header as an all 'Z' driver or create
    > board specific header models. If you're simply cobbling together your own
    > system model then adding the header to the model adds no real value and,
    > as I explained above, takes more effort and makes it less clear about real
    > signal directions.
    >
    > From a simulation perspective, no they are not equivalent, because an 'in'
    > pin can not have any drivers on it and an 'inout' is a driver even if that
    > driver is always disabled. It won't compile.


    Hmm. Yes, I need to simulate it as well.

    Brad Smallridge
    AiVision
     
    Brad Smallridge, May 8, 2007
    #3
  4. Brad Smallridge

    Guest

    On May 8, 9:18 am, "Brad Smallridge" <>
    wrote:
    > Yeah KJ, this harps on something else I never really understood about VHDL.
    > How does one simulate the entire board? If the top level is your FPGA design
    > then how do you simulate, for example, the FPGA working with a memory chip?
    > What do you mean by "your system level model"? Do you have a level above
    > your FPGA design?
    >


    The answer to the last question is "yes"; the FPGA is not the top
    level.

    You create a file for the entire board. Your FPGA is one component,
    memory is another (simulation model from Micron, for example), etc.,
    etc. You can even have models for devices connected to the board
    (terminals, networks, etc.)

    GH.
     
    , May 8, 2007
    #4
  5. Brad Smallridge

    KJ Guest

    "Brad Smallridge" <> wrote in message
    news:...
    >> Yes...either that or don't model the header at all. The mother board and
    >> daughter board will each have an entity definition which will define the
    >> I/O signals for the board (which would correspond to any
    >> headers/connectors that are on each board). Your system level model of
    >> these two will instantiate each of these two entities and then connect
    >> them however it is they are meant to be connected in a real system.

    >
    > Yeah KJ, this harps on something else I never really understood about
    > VHDL.
    > How does one simulate the entire board? If the top level is your FPGA
    > design
    > then how do you simulate, for example, the FPGA working with a memory
    > chip?
    > What do you mean by "your system level model"? Do you have a level above
    > your FPGA design?
    >

    You write more VHDL to get your models for stuff on the PCBA. Sometimes my
    top level for simulation is the PCBA model, other times it is something
    above the PCBA. So I might have entities called 'System', 'My_Board',
    'My_Fpga' which model more and more of whatever the entire system it is.
    How high up (or not) is a function of much I think needs some detailed
    modelling. The 'My_Board' code would instantiate the FPGA and whatever
    components (memory, A/D converters, etc.) that I need models for. The
    'System' code would instantiate 'MyBoard' along with whatever other
    components are needed in the system. Where I stop in detail depends on the
    project and how much detail I think I need. Sometimes more accurate is
    better, some cheap and easy is.

    KJ
     
    KJ, May 9, 2007
    #5
    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. Replies:
    43
    Views:
    1,326
    Oliver Wong
    Dec 9, 2005
  2. dont bother
    Replies:
    0
    Views:
    804
    dont bother
    Mar 3, 2004
  3. =?ISO-8859-15?Q?Fr=E9d=E9ric_Lochon?=

    connecting std_logic inout ports and std_logic_vector inout port

    =?ISO-8859-15?Q?Fr=E9d=E9ric_Lochon?=, Nov 6, 2007, in forum: VHDL
    Replies:
    3
    Views:
    858
  4. Ken

    inout to inout

    Ken, May 9, 2008, in forum: VHDL
    Replies:
    2
    Views:
    608
    Aiken
    May 9, 2008
  5. THurkmans
    Replies:
    14
    Views:
    1,821
    Mike Treseler
    Aug 11, 2009
Loading...

Share This Page