Hi Thoma,
you can also use so called "unconstrained types". The beauty being that
the vector widths are decided by the hierarchical layer in which the
unit is instantiated. The vector width can in fact be propagated through
multiple levels.
The catch to using unconstrained type is that you also need to then
add additional code to test and verify that it works with 'unexpected'
vector ranges when instantiated. The downside to using unconstrained
vectors in the OP's case are:
- Additional code is typically needed to 'normalize' the vectors,
converting any vectors that are (0 to n) into (n downto 0) for example
if that's how the rest of the code is expecting them. Typically that
code would be more typing than the additional amount of typing in the
entity to explicitly define the vector size and direction.
- Additional code is typically required to make sure that vectors that
have size relationships do in fact have them. In the OP, 'entrance',
'selection' and 'sortie' all need to be of the same size so the
architecture would typically have to have this check as an assertion.
Again, this is more typing then by defining the vector size and
direction in the entity.
- If you don't add the additional code to handle the above bullets,
then you've created a potential problem for some user down the
road...long after you (or whoever wrote it) has forgotten the detailed
dependencies and will now need to (re)discover them.
- Any usage errors don't get caught until you start the simulation as
opposed to being caught as soon as you compile the file...wasted time
and potentially more rework to other code because the problem gets
caught later.
- Usage of the entity by someone else (or the same person later down
the road) is less clear because relationships that are expected (i.e.
the above mentioned vector directions and vector size relationships)
are buried in the architecture either explicitly in assertions (if
that extra code was added) or implicitly because the sim crashes. I'd
much rather have those relationships explicitly defined on the entity
and not have to wade through somebody's code trying to discover what
they are.
The above mentioned downsides are neatly avoided by defining a generic
and then defining the vector sizes all in the entity. The only
downside to that approach is to the user of the entity in that they
must now specify the value for the generic. This can easily be
handled cleanly by specifying that value by use of the 'length
attribute. In the OP's case, proper use of the entity would be of the
following form and would work regardless of changes in size of the
vectors.
The_Shifter : entity work.barrelshifter
generic map(Width => entrance'length)
Port map(entrance => entrance,
selection => selection,
sortie => sortie);
Unless you can prove your design works with all abuses of vector
directions and sizes you should probably limit it to the forms that
you have tested and verified and make it easy on the user by defining
the tested relationships right on the entity via generics and
explicitly defined vector sizes and directions. If you want to go the
extra mile and insure that it works with all forms, go for it...but
also first yourself if that extra work is within the scope of what the
boss is paying for right now or if this is something that is only
important to you...and why? When starting from scratch, most entities
will not benefit and simply incur costs now (extra time) and later
(rediscovering implicit assumptions).
In my opinion, this particular case is probably not a good use of
unconstrained types because it creates additional work with no
benefit...ask yourself, what's the upside here?
Kevin Jennings