Thomas Stanka said:
AFAIK is an VHDL integer defined as at least 32 bit but allowed to
have more than 32 bit (eg 64bit on 64bit OS) (my knowledge may be out-
of-date with the actual versions of VHDL 200x, but it should be valid
for at least VHDL87.)
A counter with full integer width may be 32 bit, but may also be 63
bit or 64 bit depending on the internal integer representation.
No. Integers are defined in the VHDL package standard as...
type integer is range -2147483648 to 2147483647;
This is good practice to catch out of range during simulation, but
gives you a lot of work for formal verification for example.
Can you explain why the extra work for formal verification? I would think
that what is being formally verified is conformance to the specification so
if there is extra work it would imply that formal verification is verifying
functionality above and beyond what the functional requirements for the
design actually are. I haven't used such a tool, so if you do then you
could likely enlighten me a bit on this because it's not clear why formal
verification would have this extra work.
A subtype 0 to 2 results physical in two bit, but your code contains
no information what to do, when the forbidden value "11"
is reached due to any failure.
It should do whatever the functional requirements in the specification say
that it should do. If there are no such requirements then the design is
free to do whatever it wants. I might also point out that if the subtype
was one hot coded then it could be implemented as a three bit code so there
would be more than just one forbidden value.
This is especially fatal, when having
IO-ports.
Which is why you can't always impose such a constraint on an input port.
But again, it goes back to what the functional requirements in the spec say
to do. If input pins are in some 'forbidden' combination, how should the
part respond? I've yet to run across a spec from a supplier that says you
can violate some requirement and still expect it to produce the correct
output so why wouldn't the same apply to a programmable part? If such a
condition exists and the part is supposed to flag it in some manner, then
this behaviour would (should) be documented in the spec. In any case, using
integers for top level ports is not a good idea anyway but for totally
different reasons which I mentioned earlier in the thread. Blocks of IP
that are intended for 'internal' blocks do not necessarily have those same
requirements.
The next designer using your code as IP may have no clue,
that you expect some surrounding logic to ensure no forbidden input
occures.
Actually they would be explicitly aware of this because the port would be
specified with the required integer range (i.e. xyz: in natural range 0 to
99). The point is not to somehow burden down the IP user with having to
produce checking logic to insure that they are in the proper range, it is
simply to specify what the operating range actually is.
KJ