Daughter Cards, Headers, INOUT

[Brad Smallridge]

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

 

[KJ]

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:133ur6d7tln001a@corp.supernews.com...

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

 

[Brad Smallridge]

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

 

On May 8, 9:18 am, "Brad Smallridge" <bradsmallri...@dslextreme.com>
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.

 

[KJ]

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:13418o7tmg4e7e2@corp.supernews.com...

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