M
Maciej Sobczak
Guest
Hi,
I have found a coding guideline that recommends to use std_logic everywhere in preference to bit, on the basis that it can represent more states (X, Z, etc.).
What I found surprising is the implicit assumption that more states is an added value. I understand that on the module boundary the additional states can be useful, as they can model (or even enable) wider interfacing options.. But for modeling (and ultimately synthesis) of internal logic, I see no particular benefit - on the contrary, I can imagine that it might be beneficial to restrict the number of possible states as much as possible and in fact, elsewhere designers are encouraged to always use (or define) the narrowest type that covers the given context. Additional and unused states are also problematic with language constructs like the case statement, which expect complete coverage and code fragments like this:
case my_std_logic_value is
when '0' => ...
when '1' => ...
when others =>
assert false;
end case;
obviously miss the point.
So I find such guidelines contradicting each other. What is your opinion on this? Are there other aspects worth discussing? Do you feel bad using bit(_vector) for modeling internal logic?
--
Maciej Sobczak * http://www.inspirel.com
I have found a coding guideline that recommends to use std_logic everywhere in preference to bit, on the basis that it can represent more states (X, Z, etc.).
What I found surprising is the implicit assumption that more states is an added value. I understand that on the module boundary the additional states can be useful, as they can model (or even enable) wider interfacing options.. But for modeling (and ultimately synthesis) of internal logic, I see no particular benefit - on the contrary, I can imagine that it might be beneficial to restrict the number of possible states as much as possible and in fact, elsewhere designers are encouraged to always use (or define) the narrowest type that covers the given context. Additional and unused states are also problematic with language constructs like the case statement, which expect complete coverage and code fragments like this:
case my_std_logic_value is
when '0' => ...
when '1' => ...
when others =>
assert false;
end case;
obviously miss the point.
So I find such guidelines contradicting each other. What is your opinion on this? Are there other aspects worth discussing? Do you feel bad using bit(_vector) for modeling internal logic?
--
Maciej Sobczak * http://www.inspirel.com