Brad Smallridge said:
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