You're both making this harder than it needs to be with pre-processors (bad
since it goes outside the language) and configuration statements (not needed
and possibly not well supported for synthesis...haven't checked on this
lately though). The poster was simply asking about not connecting signals
to a given entity because that particular instantiation does not support all
of the bells and whistles that another instantiation might. There is no
need for anything conditional about the entity itself, there can be
conditional logic (via the generate) if needed in the instantiation of that
entity.
KJ
KJ, that is correct as far as it goes. But he also has different IO at
the top level based on which design and which FPGA package he is
targeting. For synthesis there is no "instantiation" of the top level
entity, so it is not a matter of leaving ports open in a port map. If
he were to use the "superset" top level entity, and just not attach to
some of the ports in the top level architecture, that would generate
errors in most synthesis tools.
Lower level entities can have portions of their port maps left open
(under the rules of vhdl), and only generate warnings (if that) in a
synthesis tool. I don't see a good way of escaping having two
different top level entities (and their architectures). But the top
level architectures could instantiate the same lower level entity
(with one having some open port associations). In addition, a generic
or three could be passed to that entity to alter the internal
construction (i.e. lower level modules either left out or included).
Depending on how bad you want to have a single entity, there are some
ugly, but pure-vhdl solutions. One is to have all the IO defined as a
record, whose definition is in a package. Change the package, change
the port definitions. You can have a single record port of mode inout,
or three separate record ports of modes in, out, and inout
respectively. Beware that synthesis tools are not usually very kind
in intelligently renaming record elements into pin names.
Another related option is to combine all the IO into one (or three)
std_logic_vectors whose widths are constrained by three generics (top
level generics can be set via tool (or command-line) option during
synthesis and/or simulation. Keeping track of the bit-mapping of
individual IOs in the vectors would best be handled by named constants
in a package, or by conversion to/from a record via one or more
functions in a package (the function can be overloaded based on the
width of the vector or the type of the record). But when you are
looking at a PAR report, all the ports are just going to be numbered,
and you'll have to manually convert to individual port names.
Both of these latter options are really ugly, but IMHO, better that
resorting to a non-standard preprocessor.
Andy