![]() |
What about a new attribute to access the physical representation of a signal ?
Hello,
It seems to me it can be a good idea to add to VHDL a new attribute 'repr in order to be able to access the representation of a signal (bits) that is normally not accessible on most types (integer, records, enumerates, ...). In the beginning of VHDL, if you want to do arithmetics on integers, you had to use the integer type. But there was a need of specifying a size, a range direction, easy access to the bits which was not possible with the integer type. Then came the Std_Logic_Arith which was a good solution on its time. Further, the IEEE made the numeric_std/numeric_bit packages that define the signed and unsigned type as an array of std_logic/bits. They were good packages but there is 2 or 3 things that bothers me : * Doing arithmetics on arrays seems weird to me. The VHDL compilers consider the signed/unsigned types as arrays with some functions defined on it. They don't see them as numbers which leads to some strange situations like it is possible to add an integer to an (un)signed but not to affect an integer on it. * We have already the integer type to do arithmetics on integer. After adding the signed/unsigned types, we have now to choose which type make more sense for each situation. Often they are redundant. Wouldn't be better to add some mecanisms on the integer type to allow to do what was missing on this type and have only one type (with the natural and positive subtypes) for arithmetics ? With a new attribute 'repr and the "for ... use" clause taken from Ada, I think we can add what was missing to the integer type, as shows the following code : Code:
subtype My_Integer is Natural; -- Replace natural by integer in order to have a signed integerThere is a few more things missing : * There is a limit (32 bits) on the Natural type. Then why not to add the Ada Base_Integer type to VHDL ? This type is an integer without range constraints. It is in Ada not allowed to use this type if we dont't add a range to it. * Overflow is not possible but will raise an error, which is on some cases interesting, but often we want modulo integers. So I would propose to add a keyword (for example mod or modulo) to specify modulo integers. So the declaration of My_Integer could be : subtype My_Integer is Modulo Base_Natural; -- Same as Base_Integer but for Natural numbers only And now I think that everything we can do on the numeric_std signed/unsigned types, we can also do on the integer types. Now we can use this 'repr attribute for more applications. For example : Code:
type My_Record isthe record without needing to affect each field. A second possible use : Code:
type My_FSM is (State_1, State_2, State_3);Also we can use the same tricks for the real type and we can have the same possibilities as the new float type of the float_pkg : subtype My_Real is Base_Real; -- Same as Base_Integer but for Real types for My_Real'Exponent use Std_uLogic_Vector (7 downto 0); for My_Real'Mantissa use Std_uLogic_Vector (21 downto 0); Here we can access to the exponent and mantissa either by the 'exponent and 'mantissa attributes, either as a whole by the 'repr attribute For the fixed type of the fixed_pkg, there is no equivalent standard type. We could define a Base_Fixed type which is like the Base_Integer but for the fixed types and use it as follow : subtype My_SFixed is Modulo Base_Fixed; for My_SFixed'Decimal use Std_uLogic_Vector (7 downto 0); -- I don't know if decimal is the right word for My_SFixed'Fraction use Std_uLogic_Vector (3 downto 0); -- I don't know if fraction is the right word This is equivalent as : subtype My_IEEE_SFixed is u_SFixed (7 downto -4); But it will be less cumbersome to do arithmetics on My_SFixed than on My_IEEE_SFixed. Here we can access to the decimal part and the fraction part either by the 'decimal and 'fraction attributes, either as a whole by the 'repr attribute. Here it could be interesting (I don't know) if the result of the 'repr attribute would be Std_uLogic_Vector(7 downto -4) instead of Std_uLogic_Vector(11 downto 0), but negative indexes are not allowed on Std_uLogic_Vector. So we can either create a new type like SLV but does allow negative indexes, either change the definition of the SLV to allow negative indexes. I think the latter is retro-compatible, and anyway why retrict SLV indexes to natural numbers ? So, do you think there is something wrong with that proposition or it can be a good idea for the future VHDL standards ? Jonas |
Actually, declaring a integer with a representation clause would be 3 times longer as declaring (un)signed signals :
subtype My_Integer_8 is Base_Integer; for My_Integer_8 use Std_uLogic_Vector (7 downto 0); signal A_s : My_Integer_8; subtype My_Integer_16 is Base_Integer; for My_Integer_16 use Std_uLogic_Vector (15 downto 0); signal B_s : My_Integer_16; subtype My_Integer_24 is Base_Integer; for My_Integer_24 use Std_uLogic_Vector (23 downto 0); signal C_s : My_Integer_24; Allowing the following synthax could be one way to avoid this : -- My_Integer is an unconstrained type, just as signed subtype My_Integer is Base_Integer; for My_Integer use Std_uLogic_Vector; signal A_s : My_Integer Repr_Range (7 downto 0); signal B_s : My_Integer Repr_Range (15 downto 0); signal C_s : My_Integer Repr_Range (23 downto 0); Jonas |
I forgot one thing : how the resizing should work when doing arithmetics on integers with representation clause :
Here is an example : Code:
subtype My_Natural is Base_Natural;If we would like the resizing to be made automatically, we can use a new keyword (Auto_Resize) : Code:
subtype My_Natural is Auto_Resize Base_Natural;Jonas |
| All times are GMT. The time now is 10:56 AM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.