Variable/Configurable Entity Port List

[Tricky]

On Apr 4, 12:30 am, Kevin Neilson
<kevin_neil...@removethiscomcast.net> wrote:

KJ wrote:
On Apr 2, 5:38 pm, Kevin Neilson <kevin_neil...@removethiscomcast.net
wrote:
Mark McDougall wrote:
Kevin Neilson wrote:
snip
Thanks; the "no" does indeed answer my question. I have to make a core
with a variable port list so now I know that I must do it by using a
script to generate HDL.
-Kevin-

Just curious...what is the reason that you "have to make a core with a
variable port list" rather than provide default values on input ports
that are optional?

Kevin Jennings

I have to develop a highly configurable core with many different modes.
The customer doesn't want to have a netlist with a whole pile of I/Os
that aren't relevant to his particular mode, much like you wouldn't want
a vacuum cleaner with two power cords on it when you only plan to use it
with 120VAC. It's just not friendly to deliver a netlist with, for
example, an ethernet port on it when the lines aren't connected to
anything. Or say, for example, you have a memory controller with up to
16 ports but the user has specified he wants only 3. You could still
have 16 sets of buses and make the user tie off 13 but that's lame. Or
you could concatenate all the buses together: maybe the first 8 bits
would be port 0, the next 16 bits port 1, and the next 24 bits port 3.
But that's also pretty lame. -Kevin

The only "useful" way I can see of implementing this would be to have
a wrapper around your "ugly" top level that had a separate package
with all the set up constants in it (instead , and a function to
generate the width of "my_in" and "my_out", and then connects all the
bits from these busses intelligently to the right parts of the top
level.

Personally, I would rather be presented with an entity declaration
with clearly labelled signals that I could chose to ignore rather than
a single "my_In/out" that I then had to work out where everything was
supposed to connect.

Also, if this is on an FPGA then everything, whether it's used or not,
is going going to be connected to the same pins on the FPGA
regardless, so from an implementation point of view your PIN
assignments are far easier to maintain (because they're static).