entity parameterization

[james.knoll]

I have a number of discrete output modules. Each output signal drives the gate of a FET that can switch the output high or low. The modules are all very similar. Some have outputs to drive two FETs in series, some only drive the output high, and some only drive the output low. Some example entities are shown below.

Is there a way to parameterize the entity so I don't have to have a different module for each slightly different output? I was trying to think of a way to use generics that indicate if the output should be generated or something like that. When I use an entity that has all of the signals, but portmap the unused outputs as open, I get a number of synthesis warnings.

entity discrete_output_drive_high_drive_low
port (
clk : in std_logic;
reset : in std_logic;
command : command_type;
protected_output_drive_high : out std_logic;
protected_output_drive_low : out std_logic
);
entity discrete_output_drive_high
port (
clk : in std_logic;
reset : in std_logic;
command : command_type;
protected_output_drive_high : out std_logic
);
entity discrete_output_dual_drive_high
port (
clk : in std_logic;
reset : in std_logic;
command : command_type;
protected_output_drive_high_a : out std_logic;
protected_output_drive_high_b : out std_logic
);

Thanks for any help you could give me.

Jim

 

[Andy]

Hmmm... in the code, driveIsActiveHigh is a port, but in the instantiation example, it is a generic?

Assuming it was intended to be a generic, I would go step further and make driveIsActiveHigh an unconstrained std_logic_vector generic, such that driveIsActiveHigh'length is used to constrain the size of the protected_output_drive port, and its values are used for the logic. Use just one generic, but get two pieces of information.

Even if it is intended as a port, you could still use an unconstrained SLV port the same way. Just beware that unconstrained ports on entities render them unsynthesizable AT THAT UNIT LEVEL. There must be something instantiating it to constrain the ports. I usually build a constrained wrapper for test synthesis at the unit level.

Generics are useful when you want to constrain multiple ports relative to that generic. Say you want to make sure that two variable-width ports are always the same width, you could use a single generic that both port declarations invoke in the type constraint. Otherwise, if you just made the two ports unconstrained, you should have an assertion that verifies their widths match.

Scalar generics, like N in the example, are also useful in that you can constrain the subtype of the generic for meaningful implementations. For example, declaring N as positive automatically creates an error if it is mapped to 0. An unconstrained SLV generic would not do that. On the other hand, itis easy enough to assert driveIsActiveHigh'length > 0.

Andy